LDAP Facade | Moonshot | Unity | CILogon | |
---|---|---|---|---|
Description | LDAP Facade is a solution to access non-web resources (e.g. available via SSH protocol) based on the idea of FACIUS. LDAP Facade application works as SAML SP, implements web portal for admins (management) and users (resource provisioning), as well as LDAP and REST API interfaces for non-web resources. | Moonshot is a single, unifying technology that enables you to effectively manage and control access to a wide range of web and non-web services and applications.It builds on deployed, proven technology, including:
| Unity is a complete solution for identity, federation and inter-federation management. It allows its administrators to enable authentication (or login) using various protocols, with different configurations for many relaying parties. The actual authentication can be performed using the built-in, feature-rich users database or can be delegated to one of supported upstream IdPs. The information obtained from upstream IdPs can be flexibly translated and merged with the local database (if needed) and re-exported using other protocols. Thus typical Unity use case is working as IdP or token translation service. | CILogon is a solution that provides a federated X.509 Certification Authority. The users may login to CILogon web portal using credentials from their home institutionas and request (typically short-term) certificates and the service automatically signs the requested certificates. Then the certificate may be used to access non-web resources. |
Organization | Karlsruhe Institute of Technology (KIT) | Jisc | Interdisciplinary Centre for Mathematical and Computational Modelling University of Warsaw (ICM) PL-Grid UNICORE | Cybersecurity Directorate, National Center for Supercomputing Applications, University of Illinois. |
WWW | http://wiki.data.kit.edu/index.php/LDAP-Facade | http://www.unity-idm.eu | http://www.cilogon.org | |
Maturity | There is a production instance working for Federation of non Web-based Services in the State of Baden-Württemberg, however this software relies on bwIDM specific attributes and cannot work with other IdPs. The version not relying on attributes and with some more enchancements is under development. | Moonshot has a couple of pilot (production?) installations. | ||
Protocols | ||||
Translate from | SAML 2 | SAML/RADIUS | (one time) passwords challenge-response X509 LDAP/AD SAML OpenId OAuth | SAML OpenId OAuth |
Translate to | LDAP | GSS-API | Web UI SAML 2 Web SAML 2 WS OpenId OAuth1 LDAP (under development) | X509 |
Typical Use Case | ||||
Use Case | Access to resource via ssh/sftp, gridFTP in plans | Access to web and non-web resources , e.g. GSS enabled SSH server, Apache, MS Exchange | Translation between different SSO protocols, (inter-) federation, IdMaaS | Provide certificates for accessing grid resources (gridFTP, WS, Globus Gatekeeper) |
Example | bwIDM (Federation of non Web-based Services in the State of Baden-Württemberg) | EUPanData (access to data using Shibboleth authentication) | EUDAT B2ACCESS | CILogon Service (provide certificates for InCommon federation) |
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 | In the current implementation, the IdP must support either ECP or AQ SAML profile, which is not the common case for IdPs. A solution to overcome this is under development. | |||
R12 User groups and roles | Managing groups require defining rules based on attributes exposed by IdP. | Roles are not supported by Unix accounts. | Support for groups usually requires some extensions to the (proxy) certificate (e.g. VOMS) not supported by plain CILogon. This functionality was added by AARC CILogon pilots. | |
R14 Browser & non-browser based federated access | For non-web access LDAP endpoint could be used, but:
| |||
R1 User and Service Provider friendliness | ||||
User | Requires registration step (accept terms and conditions, setup local password if required) -to be done once via web interface. Standard/legacy client software If ECP or AQ SAML profile can be used, the user may login directly to the resource If ECP or AQ SAML profile cannot be used, the user must login to the web interface prior logging to the resource (both solutions with tokens or limited time accounts) Lack of help/howto. | Standard/legacy client software works if properly implements GSS-API (e.g. web browsers) Standard/legacy client software without GSS-API doesn't work, additional components on user side must be installed (e.g. OpenSSH) Good documentation, mailing list and support | ||
Service Provider | Software is not packaged, must be compiled, deployed and configured by the admin Good installation documentation The web portal is complex -gives lots of functionality (resource management, group management, rules, statistics) Lack of portal help/howto and general documentation (description of concepts etc.) There is need for certain versions of underlying software, thus it is recommended to install some pieces manually The piloting showed some issues with underlying software (e.g. Admin interface is not completely translated to English | Complete servers on live-DVD Still there can be an issues after OS update Deployment on existing system may be more difficult Comprehensive documentation, mailing list and support Requires authentication infrastructure -the approach is good to build things from scratch, but difficult to be deployed in existing infrastructure | ||