ArisID Architecture

From OpenLiberty.org Wiki

1 Project Aristotle Architecture
2 Project Index

Project Aristotle Architecture

Project Components

The project architecture is intended to enable an API usable by application developers in multiple deployment environments. The objective is to create a common client API under which intelligent providers such as Higgins and Bandit Identity Attribute Services architectures could be used to access information from various contexts of different types. The idea behind marrying a common API with existing information providers is to create a technology "stack" capable of serving the needs of applications using personal or identity related information.

ArisID 1.0 Architecture

There are 3 major layers to this "stack" 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 ArisID Beans and ArisID API components which are 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 layers comprise functionality offered by ArisID Providers that may include intelligent routing, 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 stacks using technologies such as uses Higgins IdAS to implement the ArisID IAttrSvcsStack Interface shown in the diagram above.

WS-Policy Support

New for ArisID 1.1 is support for switchable WS-Policy implementations. The default WS-Policy implementation will continue to be Apache Neethi, however, a new handler has been added to allow for greater flexibility. To enable a new WS-Policy library to be used with ArisID, a set of "wrapper" classes will required (known as a WS-Policy Provider for ArisID) that implement the IArisWSPolicy Java interface as well as other Java interfaces for supported Privacy constraints. See JavaDocs for more information.

Handling Browser Based Assertions or 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 be able to parse the HttpServletRequest objects using a token filter that captures pushed assertions. This enables assertions received by the application server from the browser to be treated as a virtualized data source that the ArisID Provider is capable of processing. This approach de-couples applications from having to make a choice between a fixed design where information is either retrieved directly from the user or through a back-end source provider. Ideally, the application will not know whether information came via the user or from a back-end source. Instead, different users selecting different protocols in the identity metasystem can be handled flexibly 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.

ArisID API

The IGF ArisID Transactional API (a CARML-enabled API) provides a common applicaiton programming interface which developers can use to interact with Identity Services over various protocols. 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

ArisID Filter

Applications may consume identity-related information provided by a client browser or agent (e.g. SAML tokens) that may be processed by Filters that process embedded tokens and assertions so that they may be made available through the ArisID 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.