Goals and Scope of the Pilot
The pilot aims at providing access to non-web resources (e.g. sftp, ssh console) for non-grid users by exploiting the existing AAIs, without the need to obtain user certificates. The resources to which the non-web access is to be provided are considered stateful not only within single session, but also between sessions. The good example of such stateful resource is data. When stored within one user's login session it shall be also available when the user logs in next time. Thus, when the user is identified by some external identity provider, his (global) identity (and attributes) must be mapped to stable, local resources. This model requires an initial registration/provisioning step, which practically means setting up a local account.
The users shall have possibility to use the standard client software they used so far.
Another requirement is that the user needs to be logged to the same account using different access and authentication methods (e.g. sftp/password, gridFTP/X.509).
The above mentioned requirements shall be fulfilled by LDAP Facade, which allows federated authentication by simulating standard LDAP authentication.
The goals of the pilot are to:
analyze additional effort of the users to access the resources (comparing to traditional access pattern)
analyze administrative effort
analyze security aspects of the solution
propose possible enhancements
investigate how the solution may be used for guest IdPs
investigate how the solution may be enhanced to work with many attribute authorities, different than the home IdP
LDAP Facade Architecture
LDAP Facade (LDF) is a solution to access non-web resources (e.g. available via SSH protocol) based on the idea of FACIUS implemented by Karlsruhe Institute of Technology (KIT). The architecture of the solution is shown on Figure 1. The non-standard components are the web application (LDF portal) and the component with LDAP interface, that holds user accounts (LDAP Facade). The LDF portal has two interfaces:
for administrators: it performs local authentication and allows to administer the service (configuring federations, SP, rules, events, services, groups, roles, users, statistics, etc.)
for end users: it performs SAML-based authentication (Web Browser SSO profile), used for user's registration (provisioning a local account) and configuring access (registering to resources and setting local passwords)
The registered users are stored in Apache Directory that exposes traditional LDAP interface. On the other hand, Apache Directory allows for registering Java procedures that are called when some event occurs. For instance while the user authenticates to the resource server, the registered procedure may authenticate the user against his IdP. As the result, LDAP facade can be used as a local user manager as well as authentication and authorization component without any modification to resource servers (not only core code can be kept unchanged, even implementing specialized plugin is not necessary). On the other side (collaboration with external IdP), the deployment is the same as for any other SAML-based SP.
Figure 1. Architecture of LDAP Facade.
Workflow
The solution requires prior resource provisioning/registration, which is performed via web application and SAML WebSSO profile. The local account is provisioned in this step.
The resource server has LDAP user management functionality configured with LDAP Facade as LDAP server. While accessing the resource the mentioned LDAP interface is used for user authentication and as a source of user accounts and groups.
There are theoretically 3 login alternatives to access to the resource:
Enchanced Proxy - requires full trust to the resource server and SP as they are able to observe user’s password. The client software is not modified, the user sends (IdP) password to SP (via resource server). SP authenticates the user and retrieves assertions from the IdP using SAML ECP profile.
Enchanced Client - requires modifications on client side. In this mode, the user has to run a program, that acquires the assertion (using SAML ECP or SAML WebSSO profile) prior running the client and pass the cooked up password to the client. The acquisition of the assertion and access to the resource may also be performed by a single (but non-standard) client.
Local Authentication – the authentication is performed by Service Provider using SAML Attribute Query profile.
Alternatives practically implemented and tested are described later on.
Implementation and Deployment of the Pilot
Stable version of the LDAP Facade
This branch of the software (v. 2.5.7 was tested) is used in bwIDM (Federation of non Web-based Services in the State of Baden-Württemberg) service in production mode. The login alternatives in use are Enchanced Proxy and Local Authentication. Piloting this version shoved some limitations:
- Mapping user to local username and groups is based on bwIDM specific attributes (rather not supported by any IdP outside bwIDM federation). The source code of LDF had to be modified in order to overcome this and enable user login to the LDF portal and resource.
- SAML ECP and AQ profiles are rarely supported by IdPs.
By the way of work on this version, a solution to login to the resource using pair of cryptographic keys was implemented.
Development version of the LDAP Facade
In order to overcome the above limitations some development on LDF is in progress. The tested version introduces "zero attributes" policy, so that the user may login independently on the set of attributes provided. For SAML profiles limitation there are two solutions:
- The user logins (using WebSSO) to a LDF portal and obtains one-time token. Then the token may be copied to the clipboard and pasted as password in the client application. The token is verified while authentication on the resource. This solution is implemented and was successfully tested.
- The user logins (using WebSSO) to a LDF portal and the account is activated for short, limited time. The user must login to the resource with local credentials within this limited time. In particular, when the pair of keys is used for authentication, there is no need to provide password or token. Then this time limit is verified while authentication on the resource. This solution was proposed, but not tested.
Effort and user frienliness
User side:
Supports 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. Then, depending on the solution, the user must pass an obtained token as a password to the client application or login with pair of keys within limited time.
Lack of help/howto.
Software is not packaged, must be compiled, deployed and configured by the admin
Good installation documentation
No modification to the software on resource side (e.g. standard SSH server can be used), only the proper configuration of authentication and authorization mechanisms must be performed (LDAP, PAM modules)
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
Admin interface is not completely translated to English
Security aspects
The solution is correctly designed from the security point of view in general.
- The authentication to the resource is done against user's home IdP, but must be carefully configured (PAM module) otherwise the user may login using local password. (the authentication information is up to date)
- The ECP solution requires the use trust the resource provider, as password to IdP is passed through the service, other solutions lack this drawback.
- The user has to register to the resource and confirm terms and conditions (provider's interest is taken into account)
- There is no possibility to lock an access to resource for unwanted user by resource/LDF administrator (the admin may deregister the user from the resource, but the user may register again himself).