The Atricore Identity Bus

Overview

Atricore Identity Bus is designed to provide the foundation for next-generation federated identity services in a secure and easy-to-manage implementation. Atricore Identity Bus works with existing enterprise identity and access management infrastructure from a variety of vendors out of the box, and it easily scales and adapts to meet future identity and access management requirements.

In short, the Atricore Identity Bus enables out-of-the-box Identity Federation for organizations requiring to connect disparate business applications both within and across corporate boundaries, enabling substantial cost reduction, creating new revenue streams, and provide greater convenience, choice and control for end users.
The Atricore Identity Bus allows to both provide and consume identity services, such as standard-based Federated Single Sign-On, with virtually 0% re-engineering effort of the existing organization’s identity infrastructure and application installed base.
The Atricore Identity Bus represents a piece of software that lies between the organization’s identity infrastructure and internet-facing applications expanding the reach and experience of the enterprise and its users by enabling seamless interoperability amongst potentially incompatible identity protocols, processes and data for transparently achieving the Federated Identity advantages.

Built from the ground up to support the Security Assertion Markup Language Release 2 (SAML), WS-Trust, Service Provisioning Markup Language (SPML) .

Foundation

The Atricore Identity Bus Identity and Access Management Platform architecture has the following fundamental characteristics : process-driven, service orchestration, domain-centered, rule externalization and collaboration through bus-based message exchange.

Process-driven
Any Identity and Access Management use-case realization involves several platform-specific intertwined tiers using potentially complex message exchange patterns and related protocols. In traditional Identity and Access Management applications, this often means introducing all sort of tier-specific technical platform couplings onto the different interacting parties and thus leaving the identity and access management domain logic scattered over the use-case participants. This produces software that is not scalable and uncapable of handling the cross-cutting variability requirements which drive enterprise identity and access management scenarios.

The Atricore Identity Bus architecture tackles this issue basing on this axiom: an identity and access management process is just a business process. This is realized by describing an identity and access management process through business process descriptors capable of being executed by a Business Process Management System (BPMS).
The overall increase in the abstraction level allows a technology-agnostic view of identity and access management processes, cutting down dramatically the domain logic segmentation factor since every activity is driven by the process.

Service Orchestration
The realization of an identity and access management-related usage scenario, such as federated single sign-on, usually depend on multiple interacting components around a set of agreed contracts which are spanned over multiple application and transport protocols. This increases the application complexity by promoting the coupling of the domain logic with the messaging logic, such as message formatting, handling and delivery. Also, having these inherently complex service interaction patterns implemented using general purpose programming languages, increases significantly the development time and learning curve.

The Atricore Identity Bus architecture applies the Separation-of-Concerns (SoC) principles, by leveraging identity and access management features through collaborating fine-grained identity and access management services built around a set of common transport-agnostic and standard-oriented contracts.
The messaging flow is described declaratively through identity mediation rules which, upon interpretation by the Identity Mediation Engine, realizes identity and access management protocols by delegating execution to orchestrated services.

Domain Centered
Identity and Access Management frameworks and products tend to pollute consumer business application with all sort of technology bounds, with little or no semantics of the identity and access management domain. In order to express an identity and access management intent, the user is required to adhere to the specific implementation abstraction level, thus being exposed to unnecessary complexity most of which related with the inner workings of the identity and access management service being consumed. Furthermore, the coupling of the consuming application with the implementation details, doesn't allow such applications to scale well when faced to technological and functionality changes or when existing identity and access management platform functionality calls for extension in order for new business use-cases to be enabled.

Within the Atricore Identity Bus platform identity and access management functionality, such as new authentication protocols or security technology, can be implemented in a domain centered fashion, avoiding the specific technical architecture to pollute the way functionality is offered and avoiding altering predefined platform contracts. This way service provisioning interfaces are kept close to the domain, stable and implementation-agnostic.

Additionally, the domain-centered approach is realized by increasing the abstraction level through the declarative definition of identity and access management processes and identity mediation rules, independently of the underlying technical architecture that such processes require for functioning.

Rule externalization
Identity management applications, when performing message handling, require to trigger domain-specific validations related with incoming and outgoing message consistency, user identity information assertions, conditional execution evaluation to name a few. Such validations, since low variability is usually expected in most common scenarios, are implemented by using the general purpose programming language used by the service or component triggering such validations. Whereas validations in such scenarios are usually self-contained and slightly affected by functional changes, in multi-protocol and highly dynamic environments subject for instance to service hot-activation, and having identity and access management concerns potentially cross-cut the specific business concerns, a more flexible approach is required.

Within the Atricore Identity Bus platform identity and access management validations are considered business rules being held outside the scope of a specific application or component: business rules are described using a Domain Specific Language (DSL) and executed by a Business Rule Management System (BRMS). Business rules become available for being triggered by any component in a distributed fashion. This brings among other things, more productivity in implementing Identity and Access Management Protocols by fostering reuse and lowing the entry barrier for rule definition. On the other side, business-sensitive and deployment-specific identity and access management rules can be introduced without affecting the IAM core nor its services.

Collaboration through bus-based message exchange
A typical identity and access management solution requires leveraging multiple interrelated protocol stacks and its message exchange patterns. For instance, one protocol stack can be based on other stacks or used within one or more stacks with a broader scope. Additionally, such identity and access management protocols require to be bound to specific transport protocols in order for implementing services to be consumed. Furthermore, depending on the target execution architecture and deployment constraints, protocols and its supporting services must be enabled or disabled accordingly.

The commonly used approach is to have an identity and access management facility which is capable of handling the whole set of identity and access management protocols, the delivery of the corresponding messages and the supporting logic, while providing a metadata facility to the user for supporting the introduction of the necessary variability and defining target deployment requirements.

The approach used within the Atricore Identity Bus platform is to separate the messaging from the identity and access management infrastructure, and realize coarse-grained identity and access management services through transport-agnostic collaborating and fine-grained services.
The separation of the messaging infrastructure from the identity and access management one is achieved through the use of the Service Bus pattern for allowing to mix-and-match network and identity services and introduce the required variability for a specific deployment scenario. Since a transport-agnostic message bus is used, identity and access management and supporting protocols are decoupled from the mechanism its corresponding messages are delivered, supporting the introduction of deployment-specific message transformation and routing.
Furthermore, identity-related features are enabled by plugging the corresponding identity services onto the Service Bus, allowing specific business components to introduce business-specific variability without affecting the Identity and Access Management platform core and its components.

Identity Capability

The essential building blocks of the Identity Bus are Identity Capabilities. An Identity Capability represents the realization of a group of cohesive Identity and Access Management (IAM) features.
By deploying a capability onto the Identity Bus, specific IAM services become available to Identity Appliances and in turn to Identity-sensitive business applications and their users.

The Atricore Identity Bus runtime provides Identity Capabilities with the ability to realize complex Identity and Access Management integration scenarios by adopting a declarative approach based on Business Process Management (BPM). BPM offers a structure and approach for designing business actions/transactions and executing them preferably using automated processes, actions, tasks and flows.
The Planning Engine is the Atricore Identity Bus component responsible of handling the execution of Identity and Access Management BPM processes specified using the JBoss jBPM Process definition language (jPDL) .

Example Identity Capabilities include SAML Single Sign-On, WS-Trust Security Token Service and JOSSO (Java Open Single Sign-On) to name a few.

An Identity Capability provides :

• Identity Plans and Fragments: defines IAM-specific logic realized as BPMS process descriptors . They are executed by the Identity Planning engine.
• Identity Plan Actions: Referenced from identity plans for realizing their intent. They are contributed to the Identity Planning Engine to support Plan execution.
• Identity Mediation Routes : defines IAM-specific messaging processing rules realized as declarative route definitions. They are executed by the Identity Mediation Engine.
• Identity Mediation Component : used as the building block of Identity Mediation routes for exposing fine-grained IAM-specific routing and mediation logic. They are leveraged from Identity Mediation Routes.
• Contract Bindings : Message types and Service bindings for IAM protocols for providing strict semantics to mediation message exchanges and enabling standard compliance such as SAML.
• Security Token Emitters : Issuing and exchanging components for protocol-specific security tokens
• Security Token Authenticator: asserts a security token of the types handled by the identity capability
• Metadata Profiles: Metadata formats for the protocol being realized by the Identity Capability. Used for exposing Capability-specific entities such as Identity and Service Providers.

Identity Appliance

An Identity Appliance is the Atricore Identity Bus deployment unit for packaging identity and access management configurations and deployment-specific artifacts for customizing the behavior of the product. Identity Appliances build on Identity Capabilities for enabling Identity and Access Management features.

An Identity Appliance configuration and deployment model is based on declarative contributions which allow composing the chosen target deployment style – through mix and matching the features offered by Identity Capabilities – and extending the Atricore Identity Bus behavior in terms of exposing business-specific IAM endpoints to consumers as well as the backing services for realizing these.

An Identity Appliance can contain one of more Identity Appliance Units (IDAU) which act as a finer-grained deployment units intended for grouping cohesive IAM settings and extensions such as for instance the ones required for enabling an internet-facing portal to honor assertions by providing the Single Sign-On experience to users.

The mechanism to expose Identity and Access Management services to partner sites, such as Federated Single Sign-On, is by deploying Providers.

Providers can be of two types, Identity and Service Providers. By defining an Identity Provider is possible to enable the Identity Provider operational role, therefore the realization of an authoritative entity responsible for authenticating an end user and asserting an identity for that user in a trusted fashion to trusted partners.
By defining a Service Provider, the Service Provider operational role can be realized which allows to offer services or share resources by relying on the assertion information about a user produced by a trusted Identity Provider.

A provider contains in turn channel definitions which are used to specify a set of identity services targeted to a specific partner site. The specific services that are exposed to the partner site are specified by including endpoints definitions to the channel. Endpoints specify the type of service offered as well as the protocol and transport through which they're available for consumption.

The Identity Bus Architectural Style

The Identity Bus product line provides, in addition to the set of IAM contracts – such as the aforementioned ones – a default implementation for the corresponding application containers, protocol stacks and the underlying infrastructure. Since the technical architecture clearly separates specification from implementation, any of the IAM concerns may be realized by a different component .
Let’s have a look at the core containers :

• Identity Mediation Engine : built on Apache Camel. Identiy Mediation rules are described using the Camel Domain Specific Language (DSL) . Identity Mediation components are realized using Apache Camel SPIs such as the Consumer and Producer .
• Identity Planning Engine : built on JBoss jBPM . Identity Plans and Fragments are described using the PDL schema while the supporting Identity Plan Actions are realized using jBPM Actions.
• Security Token Service: Realized as an Identity Capability based on the default architectural style.
• SOA Stack: Based on Apache CXF.
• OSGi Microkernel : Based on the Apache Service Mix kernel which is in turn based on Apache Felix.
• IoC Container : Spring Dynamic Modules
• Web Container : Based on the PaxWeb Bundle which leverages Jetty.

The following diagram shows a sample Identity Capability implementation realizing the default Identity Bus architectural style.