This article explains how to use TrustedX to implement the authentication and authorization methods in Web environments.

Authentication and Authorization Methods

As the number of applications and users increases, identity and access right administration becomes a tedious and error-prone task. And so, users have to go through the bother of re-authenticating themselves for each application, using different credentials, and sometimes, even different authentication methods.

A set of applications can create a security domain by delegating its authentication and authorization processes; in this way, the applications in the set share a security token generated by an identity provider. This means that the overall administration of digital identities and their access rights is simplified and is very trustworthy. Moreover, users have the possibility of accessing all the applications with a single authentication process (Single Sign-on).

The SAML  (Security Assertion Markup Language) and XACML (eXtensible Access Control Markup Language) standards define the interchange of authentication and authorization data generated by the identity provider and interpreted by the applications: TrustedX natively implements the SAML standard, therefore being able to adopt the role of identity provider in the SOA- and Web service-based information systems. In the same way, TrustedX natively supports the XACML standard being able to adopt the PEP role (Policy Enforcement Point) o de PDP (Policy Decision Point).

The TrustedX Authentication and Authorization Service

The TrustedX authentication and authorization component uses SAML assertions to provide the identity declarations, attributes and authorization. In TrustedX, policies can be used to directly manage the rules governing the authorization decisions, or the task can be delegated to an external service (external Policy Decision Point) by means of the XACML standard.

The applications can use this TrustedX service with different architecture models. An intrusive architectural model requires modification of the applications so that they can delegate their authentication and authorization decisions to TrustedX, as can be seen in the below diagram.

Authentication

• The users provide the applications with their credentials for the applications to verify their identity.
• The applications forward the credentials to TrustedX.
• When TrustedX has verified the identity, it creates a new session by returning a SAML artifact (which is a reference to the SAML assertion).
• The user obtains the SAML artifact, which he will use in conjunction with future service requests.

Authorization

1. The users invoke a service request by adding the previously-obtained SAML artifact.
2. The applications query TrustedX using a SAMLP protocol Authorization Decision Query or a XACML Context Request.
3. TrustedX replies with a SAMLP protocol Authorization Decision Statement or a XACML Context Response.
4. The service will be provided if it is authorizes (the authorization decission is of type allowed) by TrustedX or an external element in which TrustedX delegates.

The non-intrusive architectural model requires an additional component that acts as a proxy or (gateway). This component is responsible for managing both the authentication and authorization requests. The service requests (A) are forwarded to the applications (D), only if authorized by TrustedX (B).

The references and/or artifacts used in exchanges are identifiers of local authentication and authorization system contexts (for example, TrustedX) which are formally represented in a standard way using SAML and XACML. In a domain that is local or of single security, exchanges can be carried out including only references and/or artefacts as context identifiers and, if required, also through formal expressions of these contexts using SAML/XACML assertions in which these are not digitally signed. However, when there are various administrative and security domains for interoperability and security reasons, contexts must always be expressed in a standard language (for example SAML/XACML) and the expressions generated in assertion form must always be digitally signed.

In order to implement Single Sign-on (one authentication process to access all applications) between domains, the clients must present SAML assertions that are signed outside of their domain. These assertions will be recognized by the federated domains, i.e. those domains with which mutual trust has been established. In this case, each party trusts the authentication processes, the assertions and the identity statements of their federated domains. In the below illustration, you will see how a previously authenticated client sends a service request (A) to applications in a federated domain. In this case, the client must add (implicitly using a reference or explicitly) its request to a signed SAML assertion. Applications, just like in the previous section, request authorization from their local trust development platform (B). As both domains had contracted mutual trust, the SAML assertion is used to apply the authorization policies, which will decide whether the applications will or will not be able to grant the service (D).

Examples of use

In the try section, you will find some Java code examples of use for the TrustedX TWS-AA  service. The examples use either the Safelayer Java API or the Apache Axis API. In particular, the samples are:

• Authentication - Login
• Authentication - Logout
• Resource use authorization

Go to discussion forum (1)