Difference between revisions of "Internet User Authorization"

From IHE Wiki
Jump to navigation Jump to search
Line 41: Line 41:
 
'''Actors & Transactions:'''
 
'''Actors & Transactions:'''
  
[[image:IUA_Actors_Figure_01.jpg|thumbnail|center|600px|'''Figure 34.1-1 IUA Actor Diagram''']]
+
[[image:IUA_Actors_Figure_01.png|thumbnail|center|600px|'''Figure 34.1-1 IUA Actor Diagram''']]
  
 
==Specification==
 
==Specification==

Revision as of 21:38, 28 September 2013


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

Assistance to sites in implementing security and confidentiality policies There are transactions defined by IHE that cross enterprise boundaries and are web-services based on ITI TF-2:Appendix V. The existing IHE profiles for an authenticated user identity (IHE Enterprise User Authentication Profile [EUA]) are not intended to function in cross-enterprise transactions. In a cross-enterprise environment it is more likely that the transactions will be going between two enterprises that maintain their own independent user directories (IHE Personnel White Pages [PWP]). This type of requirement is the focus of the Identity Federation standards. Identity Federation has received much attention by the security and the platforms industry. Identity Federation is agnostic to the type of user directory; it allows for a centralized user directory, but also supports the more powerful federation of user directories.

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.

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

Underlying Standards:

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.