Difference between revisions of "SOA3 Authentication Module"
(→Architecture) |
(→Architecture) |
||
| Line 47: | Line 47: | ||
*'''SAML Consumer''' reads and interprets received SAML assertion with attributes and/or authentication statements. This sub-module make SOA3 Authentication Module compliant with SAML Identity Federation | *'''SAML Consumer''' reads and interprets received SAML assertion with attributes and/or authentication statements. This sub-module make SOA3 Authentication Module compliant with SAML Identity Federation | ||
| − | In order to reduce the number of calls between SOA3 and LDAP directory and gCube Handler and SOA3, caching | + | In order to reduce the number of calls between SOA3 and LDAP directory and gCube Handler and SOA3, some caching elements are provided. |
== Deployment == | == Deployment == | ||
Revision as of 11:26, 27 March 2012
Overview
SOA3 Authentication Module provides Authentication as a Service. The module receives Authentication requests with userid and password, matches received information with data contained in User LDAP directory and returns the response. The response could be a Security Assertion Markup Language (SAML)[1] assertion containing authentication information and user attributes, if the authentication succeeds, an error message otherwise. The module is compliant with LDAP providing high performance and an high capacity and could be, if required, totally decoupled from the rest of the architecture in order to obtain a zero-dependencies model.
Key features
- Flexible authentication model
- Based on userid/password or a personal X509 certificate
- RESTful interface
- decouples the module from gCube infrastructure: zero-dependencies model. Anyway the module is also usable as Java Library
- Based on SAML
- user attributes loaded from LDAP directory are inserted in a standard SAML Assertion
- High performance and scalability
- statelessness, REST communication and LDAP based authentication
Design
Philosophy
Standards and performances are the most important features of SOA3 Authentication Module. Since Authentication Module is the entry point of an infrastructure, it should be closed enough to be secure and open enough to allow interoperability. SAML standard has been chosen to format authentication assertions and to carry user attributes. It is also used for Identity Federation: this means that a SAML compliant authentication module can easily became member of a SAML federation, for example, a Shibboleth [2] based federation. High performances are obtained using LDAP for user management. Its reference open source implementation, OpenLDAP [3] is optimized to provide high performance even with an high number of entries. Anyway, no assumption is done on LDAP implementation choice, so also a proprietary implementation can be used, such as Oracle Internet Directory [4], supporting billions of entries. Since authentication module can potentially receive a great amount of calls, optimal performances are one of the primary requirements.
Architecture
The coarse grain functionality of the module is:
- to receive REST (encrypted) authentication requests containing userid and password
- to return a signed SAML authentication assertion containing authentication information (authenticator id, timestamp and expiration time) and user attributes (at least user role)
The fine grained functionalities are provided by the sub-modules, in particular:
- Authentication Engine uses data loaded from LDAP directory to decide if received credentials are valid or not
- LDAP Connector access the directory in read only mode. It is used for userid/password checking and for attribute loading
- Identity Provider associates to valid received credentials an identity valid inside the infrastructure, in particular:
- Attributes loader loads required user attributes
- SAML generator generates a SAML authentication assertion with an id representing the Identity Provider, authentication time to live and attributes. This assertion is used as response in case of successful authentication
- Authentication Interfaces are RESTful, for zero-dependencies model, or Java API, for a strict integration as a Java Library
- SAML Consumer reads and interprets received SAML assertion with attributes and/or authentication statements. This sub-module make SOA3 Authentication Module compliant with SAML Identity Federation
In order to reduce the number of calls between SOA3 and LDAP directory and gCube Handler and SOA3, some caching elements are provided.
Deployment
The Authentication Module is the entry point of the secured D4Science e-Infrastructure: every request coming from the external world must be authenticated. This means that the logical deployment of SOA3 Authentication Module, as like as the logical deployment of user LDAP directory, should be performed at infrastructure level.
The Portal refers to Authentication Module to authenticate portal users and each Node calls Authentication Services in order to authenticate requests coming from external infrastructures or clients and from internal services generating calls not authenticated yet.
Use Cases
The use cases covered by SOA3 Authentication Module are described in this section.
Well suited Use Cases
The module is conceived to cover two main use cases:
- Authentication of Portal users
- Authentication of service calls coming from external infrastructures
In order to obtain access to infrastructure and VOs resources, a request must contain caller related attributes. These attributes are, in general, the roles associated with the caller, but SOA3 doesn't make any assumption or limitation on the semantic of them. In order to be associated to her attributes, the user must authenticate herself: if the user logs into the portal she inserts userid and password in the form and, if the credentials are valid, obtains the access. The portal has a client which contacts SOA3 Authorization Module sending a message with user credentials and obtaining the SAML assertion which will be used as a token to access internal resources. In the case of direct access to the services, through clients not integrated with the portal, user credentials must be sent inside the call (in a way which depends on the type of call): these credentials are intercepted by target Node and used for Authentication request to obtain the login. If the credentials are valid the Node receives as answer caller attributes by which it is able to evaluate authorization privileges (see SOA3 Authorization Module).
Less well suited Use Cases
The current design supports only Username/password factor authentication, in particular direct X509 certificate authentication is not currently supported. This use case can be currently covered only using the following process flow:
- resource request signed with caller personal certificate is sent to the target Node, which trusts the certificate and send its DN to the SOA3 User Management Module
- SOA3 User Management Module matches the DN with a registered user and answers with her attributes
- a local SAML Assertion producer generates and signs a SAML assertion containing authentication information and attributes and uses it for the authorization
This method is currently implemented for D4Science[5] infrastructure: it gives authentication responsibility to so called edge nodes, which is formally correct, but has the drawback that hedge nodes' signature must be known inside the infrastructure.
