I am trying to plan and implement a SSO solution in a corporate environment that serves intranet web applications running on CentOS:

  • Corporate portal (Drupal backend)
  • Project management (Project.NET)
  • Document collaboration system (Alfresco)
  • Helpdesk (Redmine)
  • Issue tracking (Atlassian Jira)

The authentication is successfully implemented against Active Directory through LDAP as there is support for these applications either out of the box either by a plugin.

Given that there isn't any stable native SSO plugin or module for all the above webapps, i lean towards a Shibboleth deployment as an identity provider and SSO solution. As i am not sure if this is suitable for the given situation i want to ask the following:

  • Is Shibboleth suitable to act as an intermediate to provide a SSO login in this scheme:

Active Directory <= Domain credentials <= Shibboleth => Identity => Application login

  • As far as i know, the authentication provided by Shibboleth to the application is actually achieved through web server configuration (Apache, Tomcat etc.). This type of authentication provides only the permission to just view the content of a given page or it can fully integrate with application authentication (as LDAP auth works)?
  • If the above identity login is actually working, application features for an authenticated user will still working as if the user was normally logged in with his domain credentials? (e.g. Redmine supports on the fly account creation for a successful first time domain user login).
  • Interesting question though not sure the 8 people following Shibboleth on ServerFault have detailed knowledge about this. Have you emailed the Shibboleth folk to get their take on this specific issue? – Lizz Jan 5 '13 at 5:59

An Identity Provider (IdP) handles authentication against a database or LDAP server and passes user information to an application = Service Provider (SP).

I assume you mean using the Service Provider implementation provided by Shibboleth's creators (dubbed shibboleth-sp) talking to a Shibboleth IdP.

This works by specifying which resources to protect in the web server configuration and augmenting the parameters passed the application by the attributes requested from the IdP by the SP. Said attributes must be released by the IdP to the requesting SP (attribute-filter.xml) and must mean something to the application. The IdP doesn't do access control, the application must decide how it interprets parameters received from the IdP.

So you either have an application that can talk to an IdP directly (via SAML2, e.g. Liferay EE), or you use shibboleth-sp and use the attributes to map a user to the application's roles model.

A basic case would be similar to using HTTP Authentication, disabling authentication in the application and using parameter REMOTE_USER to identify the user. Further data could be retrieved by the application in its data stores.

Overview: http://predic8.com/shibboleth-web-services-sso-en.htm

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.