Description
The goal of NIH’s Federated Identity service is to give a person the ability to use the same user name, password, or other personal identification to access multiple applications or data sources securely and seamlessly by relying on the identity provider’s authentication process rather than NIH’s. Federated Identity service is enabled through the use of open industry standards and/or openly published specifications.
This pattern presents a logical workflow for Federated Identity when a user attempts to access a protected Information Technology resource at NIH.
When the access is detected, the protected resource checks to see if the user has been authenticated. If authenticated, the protected resource checks to see if the user is authorized based on information it has available. If authorization is successful, then the application is invoked; if not, the process ends.
If the user is not already authenticated, the access is routed to either the user-centric store using the info card or PIV certificate method or routed to a directory service to select the Identity Provider. The Identity Provider (IdP) attempts to authenticate the user. If this is not successful, the process ends.
If the authentication is successful, the IdP forwards a pre-defined set of attributes for use by the relying application/relying party/service provider. A check is made to see if the account is known at NIH. If not, the service updates the local store with the identifying information forwarded by the IdP.
The attribute information is then forwarded to the application/relying party/service provider to make an authorization decision based on the information provided. If the user is authorized to access the application, then the application is invoked; if not, the process ends.
Please view the NIH Federated Identity Pattern below:
Diagram
Benefits
- Efficient and Secure: Allows a person to use the same local user name, password, or other personal identification to access multiple applications or data sources securely.
- Proven Success: Enabled through the use of open industry standards and/or openly published specifications.
- Versatile: Not bound to any specific protocol, technology, implementation, or vendor.
- Flexible: Offers dozens of products and competing standards for cross-organization identity
Limitations
N/A
Time Table
This architecture definition approved on:
June 25, 2008
The next review is scheduled in:
TBD
