• No results found

CAM2 identity platform

Single sign-on systems as we know today have the limitations already described. CAM2 framework describes a reference architecture for a middleware that extends those single sign-on systems enabling them to support context-aware multi-factor and multi-modal authentication. Its architecture respects a three-tier architectural style. The 3rd tier (or data integration and management tier) corresponds to the base identity management support and authentication pro- cessing facilities that can be provided by a base single sign-on system from which CAM2 is being extended, in order to support the integration of multi-factor validation factories. The 2nd tier (or authentication logic tier) is represented by an authentication engine layer that evaluates the context of each request and retrieves the combination of factors and modes required to per- form authentication. It is also responsible for the management of context-aware authentication policies storage and authentication delegation. Finally the 1st tier (or client integration tier) is implemented by a unified front-end that externalizes different authentication protocols and captures the authentication requests from the most variable kind of applications, constructing a uniform authentication request that is forwarded to the authentication logic layer. Figure 3.5 illustrates this model. Each tier is fully described on the next subsections.

Figure 3.5 CAM2 Identity Provider: Reference architecture

3.5.1 Client integration tier

CAM2 framework has the objective of providing single sign-on authentication for multiple types of systems and devices. Considering that, this tier supports different interaction types, which are specific to the applications accessing CAM2 compliant identity providers. The client integration tier is composed by integration modules that are responsible for adapting the client specific authentication mechanisms to CAM2ML uniform protocol. This enables the integration of CAM2 based authentication systems on already existing applications with a minimum of changes to their code (applications still have to implement interfaces for gathering multi-modal

and multi-factor validity proofs).

The registration and management of authentication policies is externalized by this tier. Ser- vice providers interact with this layer which keeps a set of application specific integration mod- ules. Both for authentication and for management, the logic of the processes is implemented by the lower layers. The communication between the client integration tier and the lower tiers is done using a CAM2ML based protocol.

This model beneficiates the applications and devices with limited resources or specific inter- action requirements, however, other kind of applications with more capabilities may access di- rectly the authentication logic layer using the messages and the protocol defined by CAM2ML.

3.5.2 Authentication logic tier

Context-aware multi-factor and multi-modal authentication is implemented at this tier. CAM2ML requests are handled at this level by three services which are responsible for policy retrieval, validation of authentication proofs and policy management and registration.

CAM2ML authentication policies map contexts, applications and assurance levels in a com- bination of authentication modes. For each policy request that the authentication logic tier receives, it evaluates the context attributes contained on the message and collects an authenti- cation policy from some repository, according with the application and assurance level that the request caries.

Policy management and registration logic is made through an administration interface that allows the insertion of new policies and edition of existing ones.

This tier handles CAM2ML authentication requests. It relies on the lower tiers and on the inner policy repository to perform context-aware multi-factor and multi-modal authentication. The process is divided in the following steps:

• Firstly the context attributes contained on the request must be evaluated. If there is any applicable authentication policy then the process follows to the next step.

• If the first step succeeds, the authentication proofs are evaluated. Each factor is delegated to a specific authentication module resident on the data integration tier ( will be discussed later). If, and only if, all individual authentication processes succeed, the whole multi- factor process also succeed and a new authentication assertion is generated.

The evaluation of the authentication environment both during the policy retrieval and on the authentication process is redundant, however it is necessary in order to maintain the stateless- ness of the interaction model. This property gives subjects the possibility of retrieving a policy only once and using it for multiple authentication events. On the other hand, online context evaluation allows real-time impact after changes on authentication policies without the need of any configuration.

3.5.3 Data integration tier

The first tier maintains access to a set of specific authentication modules. These modules may perform static unifactor or multi-factor validation implemented by instances of typical single sign-on authentication bases. Each of those systems may keep one or more authentication methods such as LDAP[20], Biometry or UNIX’s password files. Therefore, the data integration tier works as wrapper for multiple authentication systems externalizing an abstracted view over them. The upper tiers only have to provide identifiers for the authentication modes and the principal to be validated, along with the proofs he has supplied. The integration of all platforms is centrally managed and it may rely on standard authentication specifications such as SAML or OpenID, then taking advantage of all the benefits brought by these state-of-art technologies. The authentication logic tier relies on data integration tier to delegate the validation of indi- vidual proofs. This process is transparent for the upper tier, which is unaware of the details of integration running on the background. With that abstraction is possible to change, extend and reconfigure the underlying authentication systems without interfering with the context-aware multi-factor authentication combined process.