Internet User Authorization

Summary

Internet User Authorization Profile (IUA) - The actors in the IUA profile manage the tokens used for authorization of access to HTTP RESTful services. The Authorization Client actor provides the authorization token that is incorporated into HTTP RESTful transactions to indicate that this transaction is authorized. The Authorization Client can also manage the interactions with an Authorization Server to obtain the authorization token. The Resource Server actor provides the server side interaction to verify that the HTTP RESTful request is authorized. It blocks unauthorized uses. For authorized uses, it provides the information from the authorization token to the other server actor(s) for use as part of access control decisions.

Benefits

Conveying User Identity, Attributes, and Authorizations to a RESTful service to enable security and confidentiality policy enforcement The primary use cases are for obtaining authorization for access to a resource using HTTP RESTful HTTP transactions. There are other use cases for delegation, provisioning, etc. which are out of scope for this profile.

The authorization service is separated from the HTTP RESTful access so that it can be provided by a different organization or part of the organization than the resource service. This is driven by the requirements of patients, providers, and other users to simplify and maintain autonomy and control over authorization services. A user may interact with dozens of providers. It is difficult for the user to coordinate different authorization mechanisms with each of these dozens of providers.

This pattern is a common Internet usage and there are already vendors of authorization services that are being used to solve this problem. These include Facebook, Google, and a variety of other service providers in different commercial and governmental sectors. Some countries may use their citizen identity card to access their governmental services. These overlap with providers of authentication services. These services allow a patient to establish an authentication and authorization relationship with minimal provisioning by the healthcare provider. The user can specify “use vendor X” to their healthcare provider.

Concepts

The term “authorization” and “access control” are used colloquially for a variety of related activities. All of the concepts listed below are sometimes called “authorization” or “access control”. See the IHE ITI Access Control whitepaper for a detailed discussion of Access Control concepts. This profile will use more specific terms for each of these activities. These are:

• Provisioning – Setting up the initial rules and updating them when the situation changes. The administrator may say “Authorize Dr. X to have access”. The steps taken to make this happen are called provisioning.
• Delegation – Adding, transferring and revoking authorization from one person to another. This is closely related to provisioning. It differs in that it can only transfer authority that has already been provisioned, and it may track changes to provisioned access for the original person.
• Authentication – Determining that the actual user (at the moment of authentication) is the claimed identity.
• Authorization – Determining that the authenticated user is authorized to have access to a resource (at the moment of authorization). The profile describes how to convey an access authorization decision. It is not defining how the decision is made.
• Access Control – A system of provisioning, delegation, authentication, and authorization. It is normal to have multiple nested levels of access control. This profile is concerned with whether access is allowed to make the HTTP transaction requests to the specified resources. There are likely also building access controls, resource server access controls, and other access controls involved.

Within this profile, authorization is limited to the definition of authorization above.

Details

The IUA actors are expected to be combined with other actors that perform HTTP RESTful transactions. Combining an Authorization Client with another actor means that this other actor will provide an authorization token as part of the HTTP transaction to a HTTP RESTful server. It may perform the Get Authorization transaction to obtain the authorization token. The corresponding HTTP RESTful server should be combined with the Resource Service actor to indicate that the server can perform access control.

Authorization Client

The Authorization Client actor performs the network transactions and user interactions needed to obtain an authorization token and to attach that token to transactions to indicate that those transactions are authorized. An Authorization Client in IUA supports the following associated transactions:

• The Incorporate Authorization Token transaction – In this case the authorization token has already been obtained and is communicated as part of the HTTP RESTful transaction for some other profile or service. This token indicates that the HTTP RESTful transaction has been authorized by the Authorization Server for a particular kind of service and particular device by an authenticated person.
• The Get Authorization Token – In this use, the authorization client interacts with an Authorization service and Authentication Service as needed to obtain a token that indicates HTTP RESTful transactions for a particular kind of service and device are authorized by a particular person. This will often include various interactions with the user for authentication purposes. Those interactions are outside the scope of this profile, and may involve biometric or other identification activities. The resulting token is saved for later use by the authorization client. These tokens are not themselves protected from copying or modification, so they must be protected by the Authorization Client and transactions.

Authorization Server

The Authorization Server provides authorization tokens to requesting clients. In IUA, the Authorization Server uses an authenticated user identity, the requested HTTP RESTful service URL, and other information to determine whether HTTP RESTful transactions are allowed. If they are allowed, the Authorization Server provides a token indicating that HTTP RESTful service access is authorized.

Resource Server

The Resource Server provides services that need authorization. In IUA the Resource Server accepts a HTTP RESTful transaction request with an authorization token attached. It evaluates the authorization token to verify that the Authorization Server has already determined that this transaction is authorized. The Resource Server must enforce this authorization and may perform additional authorization decisions that are specific to the requested service. The Resource Server may then allow the transaction to proceed, subject to access control constraints that may also be in place.

Token Parameters

JWT Token -- https://tools.ietf.org/html/rfc7519

• iss -- issuer
• sub -- subject (user)
• aud -- audience
• exp -- expiration time
• nbf -- not before
• iat -- issued at
• jti -- JWT ID

Extensions Clams to JWT in IUA profile

• SubjectId -- plain text user's name
• SubjectOrganization -- Plain text description of the Organization the user is acting within
• SubjectOrganizationID -- Identifier of Organization
• NationalProviderIdentifier -- a National Identifier (e.g. USA NPI)
• SubjectRole -- Role(s) of the user (i.e. Functional and Structural)
• docid -- Document Identifier of consent - Patient Privacy Policy Identifier (e.g. BPPC)
• acp -- Patient Privacy Policy Identifier (e.g. BPPC)
• PurposeOfUse -- Purpose of Use for the request

Options

All actors are required to support at least the JSON Web Token format (JWT). They may support the SAML token format or OAuth Bearer Token options.

There are two token options:

• The SAML Token option enables integration of environments that use both SAML identity federation and OAuth authorization infrastructure. This enables the end user to control authorization of applications through OAuth when the user identity authentication is already provided through SAML identity federation.
• The OAuth Bearer Token option provides basic compatibility to minimal OAuth implementations and does not carry the healthcare attribute extensions.

The JWT Token type and the SAML Token type enable the Resource Server to make additional Access Control Decisions.

Systems Affected

Systems involved in this profile are:

• Any application or service that utilizes RESTful transactions.

Actors & Transactions:

Figure 34.1-1 IUA Actor Diagram

Specification

Profile Status: Trial Implementation

Documents: IHE IT Infrastructure Technical Framework - IUA Supplement

• Vol. 1 - Section 34
• Vol. 2(c) - Sections 3.71, 3.72

Additional Supplements: Appendix Z on HL7 FHIR

Underlying Standards:

• RFC-6749 OAuth 2.0 Authorization Framework
• RFC-6750 OAuth 2.0 Authorization Framework: Bearer Token Usage
• RFC-draft JSON Web Token (JWT) draft-ietf-oauth-json-web-token
• RFC-draft JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0 draft-ietf-oauth-jwt-bearer
• RFC-draft SAML 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants draft-ietf-oauth-saml2-bearer

updated underlying standards

• RFC7797 - JSON Web Signature (JWS) Unencoded Payload Option
• RFC7519 - JSON Web Token (JWT)
• RFC8252 - OAuth 2.0 for Native Apps

See Also

This profile supports the security/privacy model discussed in IHE Security and Privacy for HIE white paper.

Related Profiles

• Consistent Time [CT] < supports IUA in some fashion >
• XUA [XUA] < supported as a token type in IUA >

See discussion group on google+ Internet User Authorization

This page is based on the Profile Template

Current: IT Infrastructure Technical Framework.