IGF Architecture
From OpenLiberty.org Wiki
Contents |
IGF Draft Architecture
NOTE: This content will be revised and updated shortly!
Project Components
The project architecture is intended to provide an API usable by application developers in a typical application server deployment. The objective is to create a common client API under which intelligent providers such as Higgins and Bandit Identity Attribute Services architectures can be used to access information from various contexts of different types. Further this API handles and enables communication of Identity Governance information between the client and service providers.
There are 3 major layers to this architecture. The top layer represents typical application server components and applications that may consume or use identity information. Examples of this are applications, Java Authentication and Authorization Service (JAAS), session managers, etc.
The next layer are the IGF Apache components which is intended as a thin layer allowing client application developers to access identity information in a way that uses CARML declarations and de-couples the application from run-time configuration and protocol selection issues.
The bottom layer is the IGF Open Stack layers which comprise the intelligent mapping, caching, and context handling necessary to communicate with attribute authorities (databases, directories, identity providers, etc). As shown in the diagram, we anticipate development of stack that uses Higgins IdAS to implement the IGF Attribute Services Stack Interface shown in the diagram above.
Handling User Provided Tokens
In the case of protocols that pass tokens (SAML, Kerberos, STS) assertions resulting (e.g. pushed to the application server from the user browser-agent) we expect to use a Token Filter that captures pushed assertions and is essentially treated as a virtualized context provider. This approach de-couples the application from having to have a fixed design where information is either retrieved directly from the user or through a back-end source provider. In other words the application will not know whether information came via the user or from a back-end source. Instead, users can be treated in a dynamic fashion (relative to the application) and information can flow based on policy and user-consent rather than arbitrary developer decision. See Servlet Application Example for more information.
Security Token Service
In order to enable Identity Provider functionality, a set of modules will be defined to support WS-STS, ID-WSF WSP, and OpenID functionality. The security token service enables applications to become Identity Providers in addition to relying parties. Additionally, this functionality allows the stack to be deployed as a multi-protocol Identity Provider proxy or gateway to enterprise identity data sources. See Identity Provider Example below for more information.
This scenario introduces the requirement for access control and in particular Attribute Authority Policy (AAPML).
APIs & Internal Services
The following service descriptions describe components or functionality that are desirable as services. These components may be implemented in the IGF Attribute Service API or may be implemented as part of an Attribute Services Stack Implementation. At this time, it is expected that all components will be built as part of other "stacks" rather than within the core Attribute Services API.
Attribute Services API
The IGF Attribute Services API (aka CARML-enabled API) provides a common applicaiton programming interface which developers can use to interact with Identity Services. As proposed in the original CARML API specification from Oracle, the CARML-enable Identity API allows the developer to simply state identity data requirements without having to define protocols or sources from which information is held. These decisions are pushed to deployment where an administrator can configure the run-time environment based on the generated CARML deployment declaration.
Common Authentication Services (Stack)
Common Auth is a component for handling authentication and credentialing services. See the Bandit architecture page for more information.
CARML Config Manager (Stack)
This component receives CARML declarations from various applications and components running within the Application Server. It consolidates the requirements on behalf of all clients. The deployment manager can use this consolidated information to configure appropriate identity sources to be accessed via the Common Identity Provider. This deployment is expected to be automated through the use of discovery services in the future.
Role Engine / AAPML Authorization (Stack)
The role engine uses the Common Identity Provider to aggregate data to drive generation of implied, explicit, and virtualized roles. Secondly, AAPML authorization is performed to enforce local AAPML policy. AAPML policy is particularly relevant if the client code is publishing information through an Identity Provider service. AAPML policy enforcement (PEP) is always done locally where as AAPML policy decision making may be externalized to a PDP. For the open source implementation, a rudimentary PDP will be included.
Caching & Optimization (Stack)
Since a single application server may host multiple identity-services client components, it is reasonable to expect that multiple CARML declarations will be processed by the CARML Config Manager. The Caching & Optimization module can use this information to provide more predictive processing capabilities and ensure scalability. This module will demonstrate how CARML declarations can be aggregated to provide optimized query flow. For example, when a user authenticates with the application, the optimization module can also pre-fetch attributes specified by other modules deployed in the server. In theory this can reduce multiple identity operations into a single operation.
Routing / Mapping / Discovery (Stack)
This module will contain several sub-components dealing with routing (deciding which source is most appropriate for a particular request), mapping (how to map source schema to client schema), and discovery (how to determine what is available to assist in defining connections and mapping. The routing module will decide how each CARML declaration can best be met by the available identity data sources. In cases where attributes span multiple sources, the CARML declaration must be split into separate requests to fulfill the initial identity request.
Web Services / Applications
This layer is where most applications are deployed. Applications will typically interact and process identity-related data via the CARML-enabled Identity API
Filters
Applications may consume identity-related information directly from the front-end that may be processed by Filters that process embedded tokens and assertions so that they may be made available through the CARML-enabled Identity API which is then able to act as a virtualized single-source for access to Identity information.
Identity Provider Services
Identity Providers are protocols that publish claims/assertions to be provided to other external clients. The Identity Provider service provides adapters for the main web based protocols such as: SAMLv2, WS-Trust, and OpenID. This service module interacts with the identity stack by way of the CARML-enable Identity API. When pulling information from the CARML-enabled Identity API, the Identity Provider services are then subject to AAPML policy enforcement from the Role/AAPML policy component. Note: depending on the interaction profile, it is possible that a single user may interact with both a deployed web application and the Identity Provider services. An example of this is in token conversion, or claims chaining.
Examples
Servlet Application
The diagram below shows a client servlet deployed within an IGF-enabled application server.
A user-agent (top) makes contact with the web server optionally presenting a set of claims provided by an external Identity Provider. Several filters are then invoked which handle the user's session context and more importantly process any federated tokens/claims. The "Relying Party Token Filter" extracts tokens and then stores them in the IGF session cache. This enables the "Token Context Provider" (bottom) to retrieve the data and provide processed attributes as a virtualized back-end provider.
Why have tokens be parsed and virtualized as back-end data? The goal here is to abstract the client servlet application from having to deal with front-end vs. back-end data. This means that the same call to pull data from a database can be used to pull data from a federated token. Some other benefits are that the routing and mapping layers can apply appropriate transforms and prioritization of data sources. For example, depending on a particular user domain, different processing might occur. A back-end might override a front-end attribute or vice-versa.
Identity Provider Application
The diagram below shows an HR Application and IGF Framework deployed in an application server. The IGF Framework adds a multi-protocol Identity Provider capability to an HR application.
- In the above diagram, a user-agent having been given claims requirements from a relying party web site is directed to the HR Application site. In this case, the user-agent requests an attribute assertion in the form requested by the relying party. On receipt of the request from the user, the security token service uses the CARML-enabled API (aka Attribute Services API) to request the information.
Note: before processing the request, it is possible that the security requirements of the Identity Provider may have requested some form of authentication. Authentication might simply be a requirement for a set of claims from another provider (e.g. to assert the employee's identity). - Before processing the request, the AAPML policy is reviewed to see if the requestor is authorized to request the information. After successful review, the request is passed to the router.
- In this case, the router has only the HR system as a defined source. However, the mapping system will be required to map the requested attributes to the authorized internal attribute schema.
- On receipt of the request, the HR Application IGF Provider converts the request and routes it to the appropriate HR Application API or Web Service. The HR system responds according to its API.
- Before returning the request, the AAPML module reviews the data returned and validates any consent conditions that may have been defined.
- On receiving the result, the token service generates the claims response in the correct format for the requesting user-agent.
Relevant External Specifications
This project will use specifications from the original draft specifications published by Oracle (License) as well as other sources. Over time, these specifications will be replaced by recommended drafts from the Liberty Technical Expert Group.
Published On Oracle Technology Network:
- CARML - Client Attribute Markup Language
- CARML Specification(PDF)
- CARML Schema(XSD)
- Example CARML Document(XML)
- CARML Client API(PDF)
- AAPML - Attribute Authority Policy Markup Language
- AAPML Specification(PDF)
Other Sources:
- OASIS XACML TC
