1. The EGI AAI “CheckIn” Service
Peter Solagna - EGI.eu
Christos Kanellopoulos - GRNET

2. EGI CheckIn Goals Attribute Authority EGI Services EGI CheckIn IdP
Mandatory Attributes
EGI UID
First name, last name
affiliation

3. EGI AAI CheckIn Service
May 2015: Introduction of the EGI AAI Roadmap and Architecture

4. AARC Blueprint Architecture

5. Why Proxy? All EGI SPs can have one statically configured IdP
No need to run an IdP Discovery Service on each EGI SP
Connected SPs get consistent/harmonised user identifiers and accompanying attribute sets from one or more AAs that can be interpreted in a uniform way for authZ purposes
External IdPs only deal with a single EGI SP proxy
In a nutshell: EGI services will not have to deal with the complexity of multiple IdPs/Federations/Attribute Authorities/technologies. This complexity will be handled centrally by the proxy.

6. EGI CheckIn Service Today
Available via eduGAIN
IdP Discovery
User Enrolment
User Consent
Support for LoA
Attribute Aggregation
SAML2.0 Attribute Query, REST, LDAP
Support for OIDC/OAuth2 Providers
Google, Facebook, LinkedIn, ORCID
Support for OIDC/OAuth2 services
Experimental support for eIDAS
Production
Ready for production
Alpha

7. Levels of Assurance Levels of Assurance
EGI AAI proposal for 3 levels of assurance. Each level is represented by a URI:
Low: Authentication through a social identity provider →
Substantial: Password authentication at the user's home IdP →
High: Substantial + multi-factor authn (not yet supported, TBD) →
TODO: Create an appropriate document for each LoA (this may be, but does not have to be, referenced by the URI above).

8. Use cases for the LoA in EGI
allow an IdP to advertise those LoAs for which it is able to meet the associated requirements
allow an IdP to indicate the actual LoA in its responses
allow a SP to express its expectations for the LoA at which a user should be authenticated

9. EGI Unique Identifier requirements EGI User Identifier
The EGI User ID should be:
personal - used by a single person
persistent - used for an extended period of time across multiple sessions
non-reassignable - assigned exclusively to a specific person, and never reassigned to another individual
non-targeted - not intended for a specific relying party (or parties), i.e. should be shared
globally unique - unique beyond the namespace of the IdP and the namespace of the SP(s) with which the ID is shared
opaque - should (by itself) provide no information about the user, i.e. should be privacy- preserving

10. EGI User Identifier implementation EGI Unique User Id Generation
EGI User ID is created by the CheckIn service at the moment of the first user connection
The IdP/SP Proxy adds (or replaces) the eduPersonUniqueId (urn:oid: ) attribute, based on the first non-empty value from this attribute list:
ePUID, ePPN, ePTID
The selected attribute value is hashed and the “egi.eu” scope portion is added to the generated ePUID, e.g.:

11. IdP/SP Proxy technical architecture High Availability & Load Balancing
SimpleSAMLphp caches user sessions in Memcached, an in-memory key-value store for small chunks of arbitrary data
COmanage maintains EGI user profile information in PostgreSQL DB cluster; Data are synced between master (read/write) and hot standby slave (read-only queries)
Sessions are distributed and replicated among different Memcached servers, enabling load- balancing and fail-over
User requests are load balanced among multiple SimpleSAMLphp web front-ends that use the back-end matrix of Memcached servers

12. Integration with attribute authorities
Connection with Perun - DONE
Connection with GOCDB - DONE
Connection with COmanage - DONE
Connection with the new OpenConnext Attribute Aggregator – Pilot in collaboration with AARC project

13. Attribute aggregation
The EGI CheckIn supports attribute aggregation through:
SAML 2.0 AttributeQuery Attribute Aggregator
SimpleSAMLphp module
Enables SSP to issue SAML 2.0 attribute queries to Attribute Authorities that support SAML 2.0 SOAP binding
LDAP Attribute Aggregator
Allows SSP to issue LDAP queries for retrieving attributes
REST Attribute Aggregator
Allows SSP to retrieve attributes from a RESTful web service
OpenConext attribute aggregation
Java application
Handles attribute aggregation and provides REST API for accessing attribute information

14. CoCo & R&S compliance
<md:EntityDescriptor entityID="
<md:Extensions>
<mdattr:EntityAttributes xmlns:mdattr="urn:oasis:names:tc:SAML:metadata:attribute">
<saml:Attribute xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" Name=" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
<saml:AttributeValue xmlns:xsi=" xmlns:xs=" xsi:type="xs:string">
<saml:AttributeValue xmlns:xsi=" xmlns:xs=" xsi:type="xs:string">
</saml:Attribute>
</mdattr:EntityAttributes>
</md:Extensions>
CheckIn compliances
Compliant with R&S
Not compliant with CoCo but this will happen soon as the needed policies are put in place
Identifiers
eduPersonUniqueId
eduPersonPrincipalName
eduPersonTargetedID
Mail attribute
mail
Name attributes
displayName
givenName
sn (surname)
Authorization attribute
eduPersonScopedAffiliation

15. Token Translation: CILogon + RC Auth

16. User Enrollment
EGI CheckIn supports different user enrollment flows depending on the attributes released by the user’s Home Identity Provider:
Self-service Sign Up: Allows joining the EGI User Community without approval by an administrator if all the information below is asserted by the Home Organisation:
at least one of the following unique user identifiers:
pseudonymous, non-reassignable identifier (eduPersonUniqueId attribute);
name-based identifier (eduPersonPrincipalName attribute);
pseudonymous identifier (eduPersonTargetedID attribute or SAML persistent identifier)
first name (givenName attribute) and surname (sn attribute)
address (mail attribute)
role (affiliation) at Home Organisation (eduPersonScopedAffiliation attribute)

17. User Enrollment
Sign Up: If any of the required information cannot be released by the Home Organisation:
user needs to self-assert the values of the missing attributes
request must then be approved by an EGI User Sponsor
Identity linking: Allows access to EGI resources with a single personal EGI ID, using any of the linked login credentials → organisational or social

18. OpenID Connect Support
Service Providers can connect to the EGI AAI using OpenID Connect (OIDC) as an alternative to SAML2
EGI AAI OIDC Provider allows users to sign in using any of the supported backend authentication mechanisms, i.e institutional IdPs (eduGAIN) or Social Providers
Easy OIDC client registration through Client Management UI:
Obtain OAuth 2.0 credentials
Register one or more redirect URIs
Register required scopes (e.g. openid, profile, )