Difference between revisions of "SOA3 Authentication Service"
Andrea.manzi (Talk | contribs) (→Overview) |
|||
| (6 intermediate revisions by one other user not shown) | |||
| Line 1: | Line 1: | ||
__TOC__ | __TOC__ | ||
| − | =Overview== | + | ==Overview== |
| − | An high level description of SOA3 Authentication Module is given in [[SOA3 Authentication Module]]. This section provides a deeper description of the functionalities and the interfaces. | + | An high level description of SOA3 Authentication Module is given in the [[SOA3 Authentication Module]]. This section provides a deeper description of the functionalities and the interfaces. |
| Line 8: | Line 8: | ||
| − | SOA3 Authentication module receives REST messages from the gCube Security Handler ( | + | SOA3 Authentication module receives REST messages from the gCube Security Handler (whose implementation is called [[SOA3 Connector]]) with the credentials of who sent the request to a certain gCube Service, and authenticates the request. |
The Credentials accepted by the Authentication Service are: | The Credentials accepted by the Authentication Service are: | ||
| Line 22: | Line 22: | ||
The authentication process in case of Username/Password is very simple: | The authentication process in case of Username/Password is very simple: | ||
| − | 1. SOA3 Authentication Service receive a REST | + | 1. SOA3 Authentication Service receive a REST GET Message with the header: |
Authorization BASIC <Base64(Username:Password)> | Authorization BASIC <Base64(Username:Password)> | ||
| Line 28: | Line 28: | ||
2. The message is decoded and checked against the user list in the LDAP | 2. The message is decoded and checked against the user list in the LDAP | ||
| − | 3. | + | 3. If the user is authenticated a successful response is returned to gCube Security Handler, otherwise a fail is returned |
Federated Authentication for Services is slightly more complex: it requires Shibboleth Service Provider (see [[Shibboleth and gCube]]), acting as SAML Consumer installed and integrated with SOA3 Authentication Service (see [[SOA3 HowTo]]). The flow is the following: | Federated Authentication for Services is slightly more complex: it requires Shibboleth Service Provider (see [[Shibboleth and gCube]]), acting as SAML Consumer installed and integrated with SOA3 Authentication Service (see [[SOA3 HowTo]]). The flow is the following: | ||
| − | 1. SOA3 Authentication Service receive a REST | + | 1. SOA3 Authentication Service receive a REST GET Message with the header: |
Authorization FED <Base64(AssertionID)> | Authorization FED <Base64(AssertionID)> | ||
| Line 41: | Line 41: | ||
3. The Assertion is validated and, if required, authorization attributes are retrieved | 3. The Assertion is validated and, if required, authorization attributes are retrieved | ||
| − | 4. | + | 4. If the user is authenticated a successful response is returned to gCube Security Handler, otherwise a fail is returned |
| − | Federated Authentication for web portal involves Shibboleth Service Provider integrated with the Portal (see [[Shibboleth and gCube]]) | + | Federated Authentication for web portal involves Shibboleth Service Provider integrated with the Portal (see [[Shibboleth and gCube]]) and allows IMarine Portal to ''be federated'' to other SAML compliant Identity Providers. In order to allow IMarine registered users to use their identities to access external SAML compliant domains, a Shibboleth Identity Provider should be installed and integrated with IMarine Portal. |
Latest revision as of 11:47, 10 December 2013
Contents
Overview
An high level description of SOA3 Authentication Module is given in the SOA3 Authentication Module. This section provides a deeper description of the functionalities and the interfaces.
SOA3 Authentication module receives REST messages from the gCube Security Handler (whose implementation is called SOA3 Connector) with the credentials of who sent the request to a certain gCube Service, and authenticates the request.
The Credentials accepted by the Authentication Service are:
- username and password Base64 encoded
- SAML Assertion ID Base64 encoded
The endpoint of the service is:
http(s)://hostname:port/authService/authenticate
Authentication Process
The authentication process in case of Username/Password is very simple:
1. SOA3 Authentication Service receive a REST GET Message with the header:
Authorization BASIC <Base64(Username:Password)>
2. The message is decoded and checked against the user list in the LDAP
3. If the user is authenticated a successful response is returned to gCube Security Handler, otherwise a fail is returned
Federated Authentication for Services is slightly more complex: it requires Shibboleth Service Provider (see Shibboleth and gCube), acting as SAML Consumer installed and integrated with SOA3 Authentication Service (see SOA3 HowTo). The flow is the following:
1. SOA3 Authentication Service receive a REST GET Message with the header:
Authorization FED <Base64(AssertionID)>
2. The Assertion ID is decoded and used to get the actual assertion
3. The Assertion is validated and, if required, authorization attributes are retrieved
4. If the user is authenticated a successful response is returned to gCube Security Handler, otherwise a fail is returned
Federated Authentication for web portal involves Shibboleth Service Provider integrated with the Portal (see Shibboleth and gCube) and allows IMarine Portal to be federated to other SAML compliant Identity Providers. In order to allow IMarine registered users to use their identities to access external SAML compliant domains, a Shibboleth Identity Provider should be installed and integrated with IMarine Portal.
