Difference between revisions of "Internet User Authorization"

Latest revision as of 16:35, 29 November 2021

Conveys User Identity, Attributes, and Authorizations to a RESTful service to enable security and confidentiality policy enforcement

Formal Specification

IUA (html) specification

Trial Implementation

@@ Line 1: / Line 1: @@
+Conveys User Identity, Attributes, and Authorizations to a RESTful service to enable security and confidentiality policy enforcement
 __TOC__
+==Formal Specification==
-==Summary==
+===[https://profiles.ihe.net/ITI/TF/Volume1/ch-34.html IUA (html) specification]===
+* [https://profiles.ihe.net/ITI/TF/Volume1/ch-34.html Trial Implementation]
-'''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:'''
-[[image:IUA_Actors_Figure_01.jpg|thumbnail|center|600px|'''Figure 34.1-1 IUA Actor Diagram''']]
-==Specification==
-'''Profile Status:''' [[Comments| Trial Implementation]]
-'''Documents:'''
-[http://www.ihe.net/Technical_Framework/index.cfm#IT IHE IT Infrastructure Technical Framework - IUA Supplement]
-:* Vol. 1 - Section 34
-:* Vol. 2(c) - Sections 3.71, 3.72
-'''Underlying Standards:'''
-* [http://tools.ietf.org/html/rfc6749 RFC-6749] OAuth 2.0 Authorization Framework
-* [http://tools.ietf.org/html/rfc6750 RFC-6750] OAuth 2.0 Authorization Framework: Bearer Token Usage
-* RFC-draft JSON Web Token (JWT) [https://datatracker.ietf.org/doc/draft-ietf-oauth-json-web-token/ draft-ietf-oauth-json-web-token]
-* RFC-draft JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0 [http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer draft-ietf-oauth-jwt-bearer]
-* RFC-draft SAML 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants [http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer draft-ietf-oauth-saml2-bearer]
 ==See Also==
@@ Line 74: / Line 22: @@
 [[Category:Profiles]]
 [[Category:ITI Profile]]
+[[category:FHIR]]
+[[Category:Security]]
 Current: [[Frameworks#IHE IT Infrastructure Technical Framework| IT Infrastructure Technical Framework]].

Difference between revisions of "Internet User Authorization"

Latest revision as of 16:35, 29 November 2021

Contents

Formal Specification

IUA (html) specification

See Also

Navigation menu

Search