; IHE Infrastructure - Advanced Security
Documents
Resources
Learning Center
Upload
Plans & pricing Sign in
Sign Out

IHE Infrastructure - Advanced Security

VIEWS: 0 PAGES: 18

  • pg 1
									Integrating the Healthcare Enterprise


    Infrastructure - User Authentication
       Scope and Direction for Year 5




                                           IHE Infrastructure Technical Committee
                                                   Advanced Security Task Group
                                                                         Glen F. Marshall
                                                                             Robert Horn
                                                                                3-Dec-11



    Copyright © 2003, Integrating the Healthcare Enterprise, all rights reserved
                              IHE Infrastructure - Advanced Security

                                                                 Contents
1.   Proposed Profiles .................................................................................................................... 3
2.   Scope ....................................................................................................................................... 4
  2.1. Mandatory Requirements ................................................................................................ 4
  2.2. Optional Requirements ................................................................................................... 5
  2.3. Mandatory Exclusions .................................................................................................... 5
3. Use Cases ................................................................................................................................ 7
  3.1. User Logon (Single Application Service) ....................................................................... 7
  3.2. User Logon (Multiple Application Services) .................................................................. 7
  3.3. Connect To Remote Application .................................................................................... 8
  3.4. Start New Local Service ................................................................................................. 8
  3.5. User Logoff (Single Application Service) ...................................................................... 9
  3.6. User logoff (multiple application services)..................................................................... 9
  3.7. User push/pop (brief interruption) ................................................................................ 10
  3.8. Screenblanking .............................................................................................................. 10
  3.9. Force Logout ................................................................................................................. 10
  3.10.      Auto Logout .............................................................................................................. 10
4. Selected Standards ................................................................................................................ 11
  4.1. Mandatory ..................................................................................................................... 11
  4.2. Optional......................................................................................................................... 11
  4.3. Alternative User Identification and Authentication Standards ..................................... 11
5. Technical Approach .............................................................................................................. 12
  5.1. New actors .................................................................................................................... 12
  5.2. New transactions (standards used) ................................................................................ 12
  5.3. Impact on existing integration profiles ......................................................................... 13
  5.4. New integration profiles needed ................................................................................... 14
  5.5. Breakdown of tasks that need to be accomplished ....................................................... 14
6. Risks...................................................................................................................................... 15
  6.1. Selection of network identity mechanism ..................................................................... 15
  6.2. Integration with DICOM, HL7, etc............................................................................... 15
  6.3. PKI ................................................................................................................................ 15
  6.4. National Regulation ...................................................................................................... 15
7. Open Issues ........................................................................................................................... 16
8. Estimates ............................................................................................................................... 18




                                                                 -2-                                                                 3-Dec-11
                  IHE Infrastructure - Advanced Security

1.   Proposed Profiles
     We propose to extend IHE Basic Security by creating profiles for end-user authentication
     in various usage scenarios:

        A single user's access via a dedicated (non-shared) workstation

        A single user's access via a kiosk (shared) workstation.

        A single user's access via multiple workstations, either shared or non-shared

        Emergency-mode access




                                         -3-                                             3-Dec-11
                      IHE Infrastructure - Advanced Security

2.     Scope
2.1.   Mandatory Requirements
2.1.1. Common Infrastructure

       The profiles shall support common infrastructure-level workstation user authentication
       controls, as opposed to application-level controls, among all healthcare applications.

       The profiles shall support network-based authentication when a workstation is connected
       to a network.

       The profiles shall support workstation-based authentication when a workstation is not
       connected to a network.

       The profiles shall apply equally to Healthcare Information Systems (HIS), Clinical
       Information Systems (CIS), and Radiology Information Systems (RIS).

       The profiles shall be maximally compatible with the IHE Year 4 basic security profile.

       The profiles shall support configurability to conform to national data privacy laws and
       regulations.

       The profiles shall support flexibility for choices of authentication methods, strengths, and
       number of factors, e.g., passwords, biometrics, smart cards, etc.

       All audit requirements for Advanced Security are to be met in conformance with IHE
       Basic Security.

2.1.2. Intra-entity

       The profiles shall fulfill the end-user authentication the needs of a single business entity,
       which may include multiple physical locations under common security administration.
       Multi-entity considerations are deferred to subsequent IHE work but should not be
       precluded, and should be accommodated if known sufficiently

2.1.3. End-user Entity Authentication

       The profiles shall support end-user entities -- a human user or automation device --
       identifying themselves and presenting adequate proof of identity, i.e., authentication.The
       profiles shall support a single unique end-user entity identity within the business entity.
       Consideration of multiple user identities is deferred to subsequent IHE work.

       The profiles shall support a population of end-users limited to on-staff healthcare
       professionals, employees and contractors of the healthcare business entity, and
       information system administrators. Unaffiliated professionals, other entities' users, and
       patient access to healthcare data is deferred to subsequent IHE work.



                                            -4-                                            3-Dec-11
                    IHE Infrastructure - Advanced Security

2.1.4. Reduced Number of Authentication Events

       The profiles shall support serial access to multiple applications by a single user with a
       single authentication event prior to accessing the first application.

       The profiles shall support concurrent access to multiple applications by a single user with
       a single authentication event prior to accessing the first application.

2.1.5. Emergency-access Mode

       The profiles shall support users' accesses when their own unique user ID or proof of
       identity is unavailable or non-functional. This may be a policy recommendation, with a
       technical profile deferred to subsequent IHE work.

       Support for properly identified and authenticated users exceeding their authorized access
       rights is deferred to subsequent IHE work.

2.2.   Optional Requirements
2.2.1. User Data Object

       The profiles may specify use of a common user data object to supply user name,
       demographics, and other data for the user.

2.2.2. User-ID mapping

       The profiles may support mapping one authenticated user identity to its unique local
       synonyms, but support for user identification and authentication using a synonymous user
       identity is deferred to subsequent IHE work.

2.2.3. Rapid Authentication

       The profiles may support a rapid (conceptually within 5 seconds?) user identification and
       authentication process. Although optional this is strongly desired and, even if not in the
       current profile, it should inform and constrain implementation choices.

       The profiles may specify rapid re-establishment of prior user preferences (and contexts?)
       upon successful identification and authentication.

2.3.   Mandatory Exclusions
2.3.1. User Authorization

       The profiles shall not specify a mechanism to associate users with roles. This may be
       considered in subsequent IHE work.

       The profiles shall not specify a mechanism for establishing users' permissions to access
       specific application functions or data.. This may be considered in subsequent IHE work.


                                           -5-                                            3-Dec-11
                  IHE Infrastructure - Advanced Security

2.3.2. Public Key Infrastructure (PKI)

      The profiles shall not specify a PKI for user authentication. This may be considered in
      subsequent IHE work.

2.3.3. Electronic Signatures

      The profiles shall not specify an electronic signature as a method for message or data
      authentication. This may be considered in subsequent IHE work.




                                         -6-                                           3-Dec-11
                            IHE Infrastructure - Advanced Security

3.          Use Cases
3.1.        User Logon (Single Application Service)
            The local system is not in use. The actors and major transactions are shown in Figure
            3.1-1. The sequence of events is:

            1. The user initiates authentication
            2. The local authentication actor interacts with the user and the network authentication
               actor to establish that this user is authenticated.
            3. The local authentication actor retains local credentials for future use.
            4. The local authentication actor establishes a session with the single local application
               service without requiring further interaction with the user.

                                    Client                                        Kerberos
                                    Authentication                                Server
                                    Agent
                                                           Login, Get TGT


                                         Convey Identity

                               Local
                                 Local
                               Application
                                   Local
                                 Application
                                   Application



             Figure 3.1-1 User Logon (Both Single And Multiple Local Application Services)


3.2.        User Logon (Multiple Application Services)
            The local system is not in use. The actors and transactions are as shown in Figure 3.1-1.
            The sequence of events is:

            1. The user initiates authentication.
            2. The local authentication actor interacts with the user and the network authentication
               actor to establish that this user is authenticated.
            3. The local authentication actor retains credentials locally for future use.
            4. The local authentication actor establishes a session with either:1
               a) A prespecified list of local application services
               b) A user selected list of local application services (or a particular local application
                   service)
               c) A combination of a) and b).



1
    There is no standard for this part of the use case; the profile will be silent this year.


                                                         -7-                                    3-Dec-11
                    IHE Infrastructure - Advanced Security
       The list usually means “all configured local services” or “all currently running services”
       so that to the user it appears that their single authentication has caused login to the entire
       system.

       The difference between the single and multiple application login is to indicate that there
       may be a variety of differences in local applications startup that must be accomodated.

3.3.   Connect To Remote Application
       The user is already authenticated to the local system. The sequence of events is:

       1. User initiates a session with a remote application. Identified services so far include:
          DICOM, HTTP[S], HL7. For applications that utilize internal distributed structures
          such as a back end database, the application may utilize the ticket that is conveyed
          over the public DICOM, HTTP[S], HL7.
       2. The local authentication actor creates local credentials for use in requesting the
          remote application. This may involve interactions with the network authentication
          actor.
       3. Local credentials are sent to the remote application to establish
          a) The network wide unique userID for this user
          b) That this user is authenticated and
          c) That this user has made a valid request to use the remote application
       4. The remote application establishes the validity of the credentials. (If the credentials
          are invalid, the service request is refused.)
       5. Application communications proceeds without requiring any further interaction with
          the user.

                         Client                                      Kerberos
                         Authentication                              Server
                         Agent               Get Kerberos
                                             Service Ticket


                              Kerberized Connect

                        Server
                        Authentication
                        Agent                      Other


                       Server Authentication Agent is grouped with
                       another Actor that has a defined connection
                       method

                   Figure 3.3-1 Kerberized Connection to Remote Application

3.4.   Start New Local Service
       1. User initiates a session with a local service. Identified services so far include: none.



                                               -8-                                          3-Dec-11
                     IHE Infrastructure - Advanced Security
       2. Local credentials are used establish
              a. The network wide unique userID for this user
              b. That this user is authenticated and
              c. That this user has made a valid request to use the remote service
       3. Application communications proceeds without requiring any further interaction with
          the user.

                                     Client
                                     Authentication
                                     Agent

                                                 Convey Identity

                                        Newly started local
                                        application

                               Figure 3.4-1 Start New Local Service

3.5.   User Logoff (Single Application Service)
       1.   The user initiates logoff activities.
       2.   The local authentication actor removes the local credentials.
       3.   The local authentication actor ends any active sessions with remote services.
       4.   The local authentication actor instructs the single application service to switch to a
            “null user” state ready for new user sessions. This switch may be extended if the use
            of user stacking for interruption support is defined.


                               Client
                               Authentication
                               Agent                    Logoff     Remote
                  User                                               Remote
                                                                   Application
                  Initiates                                          Application
                  Logoff
                                                  Logoff

                                      Local
                                        Local
                                      Application
                                          Local
                                        Application
                                          Application




                       Figure 3.5-1 User Logoff (Single Application Service)

3.6.   User logoff (multiple application services)
       1. The user initiates logoff activities.
       2. The local authentication actor removes the local credentials.
       3. The local authentication actor ends any active sessions with remote services.


                                                -9-                                       3-Dec-11
                    IHE Infrastructure - Advanced Security
       4. The local authentication actor instructs all the local application services to switch to a
          “null user” state ready for new user sessions. This switch may be extended if the use
          of user stacking for interruption support is defined.

3.7.   User push/pop (brief interruption)
       This changes the use cases 1, 2, 5, and 6.

       For cases 1 and 2: It permits user authentication to be performed while some other user is
       already authenticated. If there is another user already authenticated, the current system
       state for that user is “pushed” onto a stack like state save mechanism. Then the user
       authentication proceeds as if this were a new users.

       For cases 5 and 6: Instead of instructing the local applications to return to the “null user”
       state, the local state from the prior user is restored.

       There are potentially difficult issues with saving the state of active sessions with remote
       services in the push/pop model.

3.8.   Screenblanking
       The screenblanking use case applies to situations where for privacy or other reasons the
       screen of the device must be blanked or obscured when the system is not in use. The
       most common approach for this is an activity timer. When the system has not had user
       input activity for a period longer than some set limit, the visible screen is blanked or
       obscured.

3.9.   Force Logout
       The Force Logout situation is related to Screenblanking. While the system is in screen
       blanking mode it may be necessary to force a logout of the currently logged in user. The
       current user might not be present to perform the logout and the screen may be blanked.
       In this situation a mechanism must be provided so that another user can log out the
       current user and then log in themselves.

       The Force Logout use case introduces issues related to aborting current activities,
       transaction rollback, etc. Dealing with the consequences of these aborts and rollbacks
       may be the responsibility of the new user.

3.10. Auto Logout
       There can be a need to force an automatic logout of the current user after some period of
       inactivity (typically longer than the screenblank period). This is similar to the Force
       Logout, but there is no new user to log in. As with the Force Logout, there are issues
       related to aborting current activities, transaction rollback, etc. Unlike the Force Logout,
       there is no new current user to accept responsibility for dealing with the consequences.
       The system must deal with the consequences automatically.


                                           - 10 -                                          3-Dec-11
                   IHE Infrastructure - Advanced Security

4.     Selected Standards
4.1.   Mandatory
4.1.1. RFC 1510 (Kerberos v5)

       Kerberos v5 provides a protocol for network-based authentication. It is a mature standard
       with wide implementation. As with many cross-industry standards, there are a number of
       implementation choices. The Year 5 IHE work will specify an implementation profile
       that supports the current scope. Consideration for smooth transition to subsequent IHE
       work, such as multi-entity support, may be made.

4.1.2. HL7 CCOW v1.4 User Context

       CCOW User Context provides a mechanism to communicate and coordinate user
       identities among applications. It depends on a trustworthy authentication mechanism,
       such as is supported by Kerberos, to establish the user's identity. The Year 5 IHE work
       will specify and implementation profile the supports the current scope. Consideration for
       smooth transition to subsequent IHE work, such as user mapping or communication of
       other user data, may be made.

4.2.   Optional
4.2.1. RFC 2798 InetOrgPerson LDAP Schema

       The InetOrgPerson LDAP schema specified by RFC 2798 is non-normative but widely
       used as a de facto standard. It supplies many use user data, and it supports multiple user
       identity synonyms that may be useful for to subsequent IHE work.

4.2.2. HL7 CCOW v1.4 User Mapping

       CCOW user mapping provides a mechanism to supply synonymous user identities to
       applications that may only know the user by the synonym rather than the authenticated
       user identity.

4.3.   Alternative User Identification and Authentication Standards
       TBD




                                          - 11 -                                         3-Dec-11
                    IHE Infrastructure - Advanced Security

5.     Technical Approach
       The following technical approach description assumes the selection of Kerberos as the
       user identification mechanism. Selection of a different mechanism will cause these to be
       adjusted.

5.1.   New actors
5.1.1. Kerberos Authentication Actor

       This is the Kerberos central authentication server and ticket server. It must be very
       securely protected. It is the agent that confirms the authenticity of the network user.
       There remain some unresolved issues regarding the interaction with this actor. There are
       various user authentication mechanisms possible, and through pluggable libraries there
       are further proprietary extensions. These need to interact with this actor.

       This actor provides the TGT that is utilized by the Network Service Ticket actor.

       This is the actor also generates tickets for services. The network user requests a ticket for
       a service (and identifies itself by means of the TGT). This actor responds with the
       service ticket to be sent to the service.

5.1.2. Client Authentication Agent

       This actor is mostly a conceptual device so that we have an actor at the client side of the
       transaction. It manages local caching of credentials, requests for TGT, requests for
       service tickets, etc.

5.1.3. Server Authentication Agent

       This actor is similarly a conceptual device. It receives a ticket for service from a client,
       confirms the user identity, manages credential caches, and provides the user identity to
       other actors and internal processes that need the user identity.

5.2.   New transactions (standards used)
5.2.1. Kerberos User Authentication

       This transaction has two parts. First is the initial authentication exchange. There may be
       pluggables, etc. to deal with the variety of user authentication devices, e.g. biometrics.

       Then this transaction generates the TGT and returns the TGT transaction after
       authentication. There may also be subsequent TGT transactions because TGTs all have
       an expiration time. IHE should recommend default expiration times, e.g. 8 hours.




                                           - 12 -                                          3-Dec-11
                    IHE Infrastructure - Advanced Security

5.2.2. Kerberos Service Ticket

       This is the transaction to obtain a ticket for use with a service. IHE needs to specify the
       granularity of service. For DICOM the reasonable granularity is the AE because
       associations are with specific AEs. For HL7 it is probably the Host. For other
       transactions (e.g. the Web) we need to define the proper granule. It is likely to be the
       Host for most protocols.

5.2.3. Kerberized Connection

       The Kerberized Connection transaction is an aspect of the connection between a local
       client and a remote server. The Kerberized Connection is defined for:

          HTTP, HTTPS – Utilize the current Kerberization standard. Each individual HTTP
           request conveys the Kerberos ticket information. This is feasible because Kerberos
           ticket verification at hosts is relatively lightweight and does not require network
           traffic.

          HL7 – Utilize the defined Kerberos option for TLS. (See note and open issues below.

          DICOM – Define a Kerberized DICOM association mechanism. Two proposals are
           feasible. (See Open Issues.)

5.2.4. Convey Identity

       There are two levels to the implementation of Convey Local activity:

          The Operating system level, utilizing tools such as the widely implemented kinit
           series. System utilities and other applications may select the Operating system level.

          The Application level, utilizing a Kerberos extended CCOW. CCOW aware
           applications may utilize the Application level locally.

5.3.   Impact on existing integration profiles
5.3.1. Basic Security

       We need to specify how the network identity is conveyed in audit messages.

       It is desirable that we avoid introducing any incompatibilities between the already
       defined Basic Security Profile and the Network Identity profile, so that compliance with
       one does not prevent or require compliance with the other.

       All audit requirements for Advanced Security are to be met in conformance with IHE
       Basic Security.




                                           - 13 -                                         3-Dec-11
                  IHE Infrastructure - Advanced Security

5.4.   New integration profiles needed
5.4.1. Network User Identification Profile

       TBD

5.5.   Breakdown of tasks that need to be accomplished
       TBD




                                       - 14 -              3-Dec-11
                    IHE Infrastructure - Advanced Security

6.     Risks
6.1.   Selection of network identity mechanism
       The Kerberos, SAML, etc. need to be resolved. There are risks with each approach.
       Kerberos is well established and widespread. It lacks support for some of the features
       defined in SAML, etc.

6.2.   Integration with DICOM, HL7, etc.
       The current protocols all lack a single standard defined mechanism to convey user
       authentication information. There are multiple methods standardized and in use for some
       protocols, e.g. HTTP; while for other protocols such as HL7 there is no established
       standard for conveying user identity. DICOM has standardized on the use of TLS to
       exchange mutual identities, but the IHE has already used that to exchange the host
       identities. If we use that to exchange the user identity we introduce a variety of problems
       for implementation and compliance with the IHE Basic Security profile.

       I have separately proposed an extension to DICOM that would deal with this for DICOM,
       but there is no assurance that this proposal will be accepted, and even if accepted whether
       it would be standardized in time for our use.

6.3.   PKI
       The entire area of PKI is being avoided because of its immaturity in terms of standards
       and implementations. This poses the short term risk that PKI solves its issues rapidly and
       becomes available on the same time scale as this IHE effort. There is also the long term
       risk that we find this solution to require major revisions when the PKI problems are fully
       resolved.

6.4.   National Regulation
       This affects both the Basic Security and this profile. There are a variety of national data
       privacy regulations. The Basic Security audit trail mechanisms introduced a significant
       potential for data gathering abuses. In some nations, Germany being a particularly strict
       example, gathering information regarding details of the daily work activity of the medical
       staff is strictly restricted. The mechanisms in the Basic Security audit trail are legal, but
       must be subject to strict controls on when and why the audit data may be gathered.

       There may be similar regulatory concerns regarding the use of a network wide user
       identity. Providing the mechanism is unlikely to be illegal, but it may be subject to some
       strict regulations regarding its use.




                                           - 15 -                                         3-Dec-11
                 IHE Infrastructure - Advanced Security

7.   Open Issues
     1. How to convey user identify for DICOM, HL7, HTTP, ….
         Tentative resolution: Use standard header in HTTP (Rob to research)
         Resolution: HL7v2 and DICOM do not support user identity; feedback need for
            this to standards groups
     2. How to manage the diverse end user authentication technologies (password, smart
        card, token, etc.) and their interaction with the network authentication server.
         Resolution: Assumed this year: user-ID and password is mandatory minimum
         Alternatives out of scope this year; will document this as non-normative annex
     3. Confirm the use of Kerberos rather than one of the alternatives.
         Resolved: postponed, pending maturity of alternative standards
     4. Interaction between the local user agent and the local applications.
        a) Application Access to TGT
             Resolved: Will be done with service tickets for Kerberized applications; not
                relevant to non-Kerberized applications
             Resolved: Will make actor disctintions between TGT obtainers, proxyable
                service ticket providers and consumers, and direct users of TGTs.
        b) CCOW user context access to TGT:
             Resolved: Explict addition to CCOW standard will be proposed to HL7,
                perhaps using authentication repository API semantics
             Resolved: Would be service ticket, not TGT
             Resolved: out of scope for this year (probably)
     5. The issues regarding logoff management, screen blanking, and automatic logoff
        remain to be resolved. Some or all of this may move to a later year, or may be only
        guidance.
        a) Logoff Management
             Resolution: Defer to CCOW specification
             Resolution: Deferred to local operating system implementation/policy; see
                #8b, below
        b) Screen Blanking
             Resolution: Deferred to local operating system implementation/policy
        c) Automatic Logoff
             Resolution: Defer to CCOW specification
             Resolution: Deferred to local operating system implementation/policy; see
                #8b, below
        d) User Push/Pop
             Resolution: Postponed; out of scope this year
     6. The details of user identity exchange needs for multiple user mapping remain to be
        resolved.
        a) Resolution: With CCOW: postponed
        b) Resolution: Without CCOW: out of scope
     7. Timebase and Secure Node actors to be added for Kerberos
         Resolution: Refer to IHE Y5 Basic Security
     8. TGT Management


                                      - 16 -                                      3-Dec-11
           IHE Infrastructure - Advanced Security
    a) TGT lifespan guidance
        Resolved: no guidance provided
    b) TGT destruction at user logoff guidance
        Resolved: should destroy TGT when user session ends
    c) TGT renewal guidance
        Resolved: no guidance provided
    d) Reauthentication guidance
        Resolved: no guidance provided
9. Rapid user authentication / user switching
     Resolved: We believe that the current year's work is consistent with this
       requirement.
     Resolved: This year's profile contributes toward the solution, but is not a
       complete specification.
10. User data object
    a) LDAP implementation/mapping to RFCs
        Resolved: will use InetOrgPerson; no extensions required
    b) Data Model itself
        Resolved: LDAP cn attribute is primary user ID
        Resolved: LDAP uid attribute is multi-valued and contains secondary
           userID-application pairs, perhaps userID@domain
    c) Administrative use cases
        Resolved: Postponed; will be identified when the LDAP implementation is
           profiled




                                - 17 -                                    3-Dec-11
                 IHE Infrastructure - Advanced Security

8.   Estimates
        Technical Committee effort for each task (scale 1-10): TBD

      Implementation/Development effort for each task (scale 1-10): TBD




                                       - 18 -                              3-Dec-11

								
To top