Authentication and Authorisation for Research and Collaboration Michał Jankowski, Maciej Brzeźniak AARC General Meeting, Utrecht Non web access May 2016 AARC SA1.3 Poznan Supercomputing and Networking Center

Local resource provisioning Setup local account To be done once, using web is possible Token translation Map „federated” attributes or group/roles to the local ones Verify the „federated” credentials while accessing the resource (e.g. to forbid users that left their home institution) Local resource deprovisioning When the local account and connected data may be deleted? Problem statement 2

The account is being created while registration step (LDAP Facade). Pools of accounts are created locally, the user is mapped to the account on the first sign on (LCMAPS). Approaches Provisioning 3

Enhanced proxy Enhanced client Local authentication PKI based authentication (GSI). Accounts with limited activity time Approaches Token Translation 4

Fact: the user’s attributes/rights are changing rarely and usually there is no need to verify all the time The assertion obtained at the login is not "continuously" verifying, but assumed as true for some (session) time Assertions signed included in X509 (proxy) certificates are valid for some time The workflow: 1.The user access the web portal, web SSO profile is used for authentication and obtaining some attributes from IdP 2.The attributes are mapped to local username, group membership, etc. 3.On the first login the user must setup local access (public key, password…) 4.The provisioned account is valid for some limited time (e.g. 12h) 5.The user must login to the non-web resource within this limited time 6.After that time the local account is locked, the user may unlock it by logging again to the web portal Issue LDAP doesn’t support locking/unlocking an account out of the box Accounts with limited activity time 5

SSH/SFTP LDAP Facade Moonshot Unity + LDAP plugin GSI OpenSSH GSI (Grid Security Infrastructure) –gridFTP VOMS + LCMAPS CILogon Unity + online CA (EUDAT B2ACCESS) iRODS Unity + iCAT provisioning script (EUDAT B2ACCESS) Kerberos Application specific LibreOffice / ownCloud integration OpenStack …. Access Protocols Pilots coverage 6

Production Designed to work with Federation of non Web-based Services in the State of Baden-Württemberg (bwIDM) Uses bwIDM specific attributes for mapping the user to account and groups The pilot required modification of the code (the mapping cannot be defined via the portal) PSNC development: key based authentication Development „Zero attributes” policy implemented (well, Uid or ePPN are used to produce username) Some issues not present in the production version (e.g. the user cannot deregister) Other features on the roadmap: OIDC for authentication LDAP Facade Piloted versions 7

Translation Services -comparison Requirements R4 Community-based authorisation R7 Federation solutions based on open and standards-based technologies R8 Persistent user identifiers R9 Unique user identities R11 Up-to-date identity information R12 User groups and roles groups based on attributes, currently support for inter-IdP groups R14 Browser & non-browser based federated access

Moonshot pilot Status and experience Moonshot installation Closed environment - all components on local VMs No federated access tested So far conclusions Installing a complete OS with server from DVD is pretty easy Comprehensive documentation But still the installed environment had an issue, solved by direct intervention of the support No security issues „by design” But intrudes „badly designed” standard ssh authentication (requires both dedicated client and server) Was it the cause of my issue? The federation must be „trust infrastructure” eduGAIN is currently not, but some work is in progress „Proxy IdP” is not a solution (TI contains also SPs) TI would solve some issues present in eduGAIN

Translation Services -comparison Protocols ServiceTranslate fromTranslate to LDAP FacadeSAML 2LDAP MoonshotSAML/RADIUSGSS-EAP Unity(one time) passwords challenge-response X509 LDAP/AD SAML OpenId OAuth Web UI SAML 2 Web SAML 2 WS OpenId OAuth1 (LDAP) CILogonSAML OpenId OAuth X509

Translation Services -comparison Typical use cases ServiceUse caseExample LDAP Facade Access to resource via ssh/sftp, gridFTP in plans bwIDM (Federation of non Web-based Services in the State of Baden- Württemberg) MoonshotAccess to web and non-web resources, e.g. GSS enabled SSH server, Apache, MS Exchange EUPanData (access to data using Shibboleth authentication) UnityTranslation between different SSO protocols, (inter-) federation, IdMaaS EUDAT B2ACCESS CILogonProvide certificates for accessing grid resources (gridFTP, WS, Globus Gatekeeper) CILogon Service (provide certificates for InCommon federation)

Translation Services -comparison Requirements Requirement LDAP Facade MoonshotUnityCILogon R4 Community-based authorisation VVVV R7 Federation solutions based on open and standards-based technologies VVVV R8 Persistent user identifiers VVVV R9 Unique user identities VVVV R11 Up-to-date identity information ?VVV R12 User groups and roles ?VVV R14 Browser & non-browser based federated access VVVV Cer t dat e

Translation Services -comparison R1 User and Service Provider friendliness 13 ServiceUserAdministrator LDAP FacadeRequires registration step Standard client software No documentation (in English) Software is not packaged, must be compiled and deployed some config might be done automatically Good installation documentation Lack of portal documentation Issues with underlying software Admin ifc not completelly translated to English MoonshotClient software must be modified Documentation in place Installing a complete OS with server from DVD is pretty easy Comprehensive documentation But still the installed environment had an issue, solved by direct intervention of the support

© GÉANT on behalf of the AARC project. The work leading to these results has received funding from the European Union’s Horizon 2020 research and innovation programme under Grant Agreement No (AARC). Thank you Any Questions?

LDAP Facade Architecture source: S.Labitzke Now SAML takes it all: Federation of non Web-based Services in the State of Baden-Württemberg, European Identity & Cloud Conference 2013

LDAP Facade Workflow Prior resource provisioning/registration via web portal and SAML WebSSO profile Access to the resource is possible in two models: Full trust the user passess his IdP password to ssh server the server verifies the password using LDAP Facade LDAP Facade authenticates the user against IdP (enhanced proxy SAML profile) Limited trust after registration the user sets up pair of keys to access ssh server the user is authenticated using the keys the server verifies the user using LDAP Façade LDAP Facade checks the user against his IdP (assertion query SAML profile)

Moonshot Architecture source:

Moonshot Workflow Prerequisites credential from Moonshot IdP trust relationship with a Moonshot Relying Party Proxy installed/configured client software server software modified/configured to talk with local RP Proxy Authentication/Authorisation the client contacts the server, usage of GSS-API is negotiated the user selects identity to be used for the particular service TLS tunnel is set from the client to the IdP thru the Service the tunnel is used to authenticate the user and to verify RP (RP name sent by the client and name of „tunnel proxy” are compared) IdP sends RADIUS Access-Accept and optionally SAML assertion to RP RP Proxy and then the service authorize the user depending on the above and on local policies

Unity Architecture source: Access via different endpoints. Each endpoint has low level binding (web, SOAP, etc.) Each endpoint is associated with authenticator(s) that collect and check credentials. Each user must be registered in a local database.