...
The most common mechanism used to bridge between IdPs and X509 are the robot certificates, which can generate programmatically short lived X509 proxies that are used to access EGI services. One of the drawbacks of this solution is that the real user identity is hidden behind the robot certificate. To partially address this issue, EGI is implementing an extension of the X509 proxy certificate that contains an ID that can identify the user if needed. This is particularly useful for accounting purposes and, at the same time, improves the overall security of the implementation.
EUDAT
The EUDAT infrastructure is implementing an AAI solution called B2ACCESS which bridges various AAI technologies used by the communities with the various technologies used by the service providers within the infrastructure. Users of the infrastructure must be able to use their home organisations’ IdPs to log in to the EUDAT infrastructure, as well as IdPs run by the user communities (e.g. CLARIN) and, when applicable, social media (e.g. Google). The user’s EUDAT identity contains attributes provided by the “home” (external) IdP, supplemented with attributes maintained by B2ACESS itself (the proxy scenario) - so every internal identity can present, for example, an email attribute. Finally, EUDAT itself can also provide a “homeless” IdP by having users authenticate using username/password.
As EUDAT runs a lot of different services internally, SPs are offered different technologies for integration with B2ACCESS. Based on work originally done in the Contrail project and carried forward by the first EUDAT project, services can choose to use SAML (using the WebSSO profile), OAuth2 (RFC 6749), or X.509 certificates. In a simple scenario, a service will use OAuth for simple access and authorisation; a more complex scenario would use SAML to authenticate and pass authorisation decisions to an XACML infrastructure. In the most elaborate scenario, users would authenticate to a (community or EUDAT) portal using SAML WebSSO (which in turn redirects to the “home” IdP); then the portal obtains an OAuth access token to grant further rights, including the right to obtain a certificate on behalf of the user from a web services certification authority (internal to B2ACCESS) - it then generates the keys and obtains the certificate which includes authorisation attributes. This scenario provides extra security compared to many of the traditional portals as the issuance of the certificate requires additional authorisation (the portal has to be registered as an OAuth client and needs to be authorised to obtain a particular user’s certificate); the management of such authorisations can be predefined administratively or by the user and can be audited subsequently. Power users can download the certificate and use it to drive non-web services from the command line, e.g. B2SAFE and data transfers. Despite its complexity, this approach offers a high degree of flexibility of integration of the many different components that comprise an EUDAT infrastructure, and many services will choose to use only the least complicated AAI mechanisms depending on their security requirements.