SOA3 Authentication Module
Overview
SOA3 Authentication Module provides Authentication as a Service. The module receives Authentication requests from external clients with userid and password, matches received information with data contained in User LDAP 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 succeeded, 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
- Userid/password authentication model
- a personal X509 certificate is not required to users
- RESTful interface
- decouples the module from gCube infrastructure: zero-dependencies model. Anyway the module is also usable as Java Library
- Standard based
- User attributes loaded from LDAP are inserted in a standard SAML Assertion
- High performance
- based on LDAP, which is particularly appropriate for authentication operations
Design
Philosophy
Standard compliance and performance are the most important features of SOA3 Authorization Module. Authentication Module is the entry point of an infrastructure and determines the balance between levels of closure and openness. In particular the concept of closure should be referred to security, i.e. making very difficult (and potentially impossible) to access the infrastructure without valid credentials. The openness should be referred to standard compliance, in authentication case SAML, providing interoperability with other infrastructure. SAML standard is also used for Identity Federation: this means that a SAML compliant authentication module can easily became member of a SAML federation[2]. The high performance are obtained using LDAP for user management. The reference open source implementation, OpenLDAP [3] is optimized to provide high performance even with an high number of entries. Since the authentication module and the user management system potentially can receive a great amount of calls, the performance should be view as one of the first requirements.
Architecture
The main software components forming the subsystem should be identified and roughly described. An architecture diagram has to be added here. A template for the representation of the architecture diagram will be proposed together with an opensource tool required to produce it.
Deployment
Usually, a subsystem consists of a number of number of components. This section describes the setting governing components deployment, e.g. the hardware components where software components are expected to be deployed. In particular, two deployment scenarios should be discussed, i.e. Large deployment and Small deployment if appropriate. If it not appropriate, one deployment diagram has to be produced.
Large deployment
A deployment diagram suggesting the deployment schema that maximizes scalability should be described here.
Small deployment
A deployment diagram suggesting the "minimal" deployment schema should be described here.
Use Cases
The subsystem has been conceived to support a number of use cases moreover it will be used to serve a number of scenarios. This area will collect these "success stories".
Well suited Use Cases
Describe here scenarios where the subsystem proves to outperform other approaches.
Less well suited Use Cases
Describe here scenarios where the subsystem partially satisfied the expectations.
