Over a million developers have joined DZone.

Developing Identity Management System with Shibboleth (Part 2)

· Integration Zone

Build APIs from SQL and NoSQL or Salesforce data sources in seconds. Read the Creating REST APIs white paper, brought to you in partnership with CA Technologies.

About this tutorial
This tutorial, the second of the three-part series, explains how to develop a single sign on based identity management system with Shibboleth IDP and SP. This will also show how you can traverse the resources of multiple applications with single login mechanism.
In this tutorial, learn how to:
  • Set up and configure Shibboleth Identity Provider and Service provider with Apache web server on Ubuntu.
  • Integrate your custom Applications with SSO feature through Shibboleth.
  • Capture user attributes from Shibboleth IDP in your application.
This tutorial assumes familiarity with some basic concepts of Identity Management and Single Sign On. Please follow the below steps for installation and set up of Application Server, Apache web server and Open-LDAP required for this tutorial.
  • Apache Tomcat 7.
 Get Tomcat & from here 
  • Java
 Download Self extracting  installer (based on you machine 32 bit or 64 bit)
  • Open Ldap
I) JAVA: JDK is installed and JAVA_HOME is set in bashrc or profile.
If JDK not installed and configure then download it from Oracle and do the following steps to set up.
Move to the directory where you have downloaded it: cd /home/kuntal/Downloads
Now execute it ./jdk-6u27-linux-i586.bin you will see a new directory jdk1.6.0_27  - - will refer this as JAVA_HOME.
Set up your JAVA home in bashrc or profile export JAVA_HOME=/home/kuntal/Downloads/jdk1.6.0_27
II) Local Domain: Create a local domain name for your IP in the network.
sudo vi  /etc/hosts and add the following entry in it:       kuntal.example.org
III) Installing OpenSSL: To install the OpenSSL general-purpose library, first determine the applicable version of the library available for your Ubuntu computer with the following command issued at a terminal prompt:
apt-cache search libssl | grep SSL
You should observe output from the command similar to the following:
libssl0.9.6 - SSL shared libraries (old version)
libssl-dev - SSL development libraries, header files and documentation
libssl0.9.7 - SSL shared libraries
In the above example, you would most likely want to install the current OpenSSL library, which appears in the output as libssl0.9.7 (like sudo apt-get install libssl0.9.7)
IV) Apache 2 Installation: The Apache2 web server is available in Ubuntu Linux. 
install Apache2: At a terminal prompt enter the following command.
sudo apt-get install apache2
SSL certificates Apache2: 
Enable SSL    sudo a2enmod ssl
Restart apache2: 
sudo /etc/init.d/apache2 restart
Create a new directory where we will store the server key and certificate:
sudo mkdir /etc/apache2/ssl 
Create a self-signed SSL certificates: When we request a new certificate, we can specify how long the certificate should remain valid by changing the 365 to the number of days we prefer. As it stands this certificate will expire after one year.
sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/apache2/ssl/apache.key -out /etc/apache2/ssl/apache.crt
Set up the virtual hosts to display the new certificate: 
sudo vi /etc/apache2/sites-available/default-ssl
Within the section that begins with <VirtualHost _default_:443>, quickly make the following changes.
Find the following lines, and make sure that they match the extensions below:
SSLEngine on
SSLCertificateKeyFile /etc/apache2/ssl/apache.key
SSLCertificateFile /etc/apache2/ssl/apache.crt
Add a line with your server name in 
httpd.conf: sudo vi /etc/apache2/httpd.conf
ServerName :  kuntal.example.org
Before the website that will come on the 443 port can be activated, we need to enable that Virtual Host: 
sudo a2ensite default-ssl
Restart apache2 :
sudo /etc/init.d/apache2 restart
Now in your browser, type https://kuntal.example.org, and you will be able to see the new certificates. 
V) Tomcat set up 
Make a directory sso:
mkdir /home/kuntal/Kuntal/sso
Move inside that directory:
cd /home/kuntal/Kuntal/sso
Extract downloaded tomcat distribution:
tar -xvzf apache-tomcat-6.0.39.tar.gz  
This will refer this extracted tomcat as IDP Server.
Make another directory for app Server: 
mkdir /home/kuntal/Kuntal/sso/appServer
This will refer the tomcat inside it as appServer. 
Copy the the tomcat extract to the appServer directory:
cp /apache-tomcat-6.0.39 /home/kuntal/Kuntal/sso/appServer
Tomcat AppServer and SSL set up:  Move to the bin directory of JAVA_HOME
cd /home/kuntal/Downloads/jdk1.6.0_27bin
Execute the following commands to generate keystore and truststore file along with their password:
./keytool -genkey -alias localhost -keyalg RSA  -keystore /home/kuntal/Kuntal/sso/appServer/apache-tomcat-6.0.39/conf/ssocert
Note:   Please write your local domain name when asked for your first name and last name.
./keytool -export -alias localhost -storepass changeit -file /home/kuntal/Kuntal/sso/appServer/apache-tomcat-6.0.39/conf/ssoclient.cer -keystore /home/kuntal/Kuntal/sso/appServer/apache-tomcat-6.0.39/conf/ssocert
./keytool -import -trustcacerts -alias localhost -storepass changeit -file /home/kuntal/Kuntal/sso/appServer/apache-tomcat-6.0.39/conf/ssoclient.cer -keystore "/home/kuntal/Downloads/jdk1.6.0_27/jre/lib/security/cacerts"
Now edit the appServer server.xml to make ssl enabled with the above certifcates:
 sudo vi /home/kuntal/Kuntal/sso/appServer/apache-tomcat-6.0.39/conf/server.xml
Update or Add(if not enabled) the following:
<Connector port="8543" protocol="org.apache.coyote.http11.Http11Protocol"         

scheme="https"  SSLEnabled="true"   clientAuth="want"           keystoreFile="/home/kuntal/Kuntal/sso/appServer/apache-tomcat-6.0.39/conf/ssocert"
truststoreFile ="/home/kuntal/Downloads/jdk1.6.0_27/jre/lib/security/cacerts"
truststorePass ="changeit"/>
Also update the default http connector and AJP1.3 connector port config:
<Connector port="8090" protocol="HTTP/1.1" 
               connection Timeout="20000" 
               redirectPort="8543" />
  <Connector port="8010" protocol="AJP/1.3" redirect Port="8543" />
IDP server will be running on 8080 for http and 8443 for https. So appServer will be running on 8090 for http and 8543 for https as we are running both server's on the same machine.Now start the appServer and check whether its running properly on the above mentioned port:
Start by executing:
Access the https from browser: https://kuntal.example.org:8543/ 
(For the first time your browser may asked to SSL certificate not trusted, but click the button proceed anyway to validate the tomcat home page)
Tomcat appServer load balancing with Apache2 web server .Configure mod_jk with Apache2 in Ubuntu. Install mod_jk: To install mod_jk in ubuntu execute the following command on the command line.
sudo apt-get install libapache2-mod-jk
Open jk.conf file to find the location of worker.properties:
sudo vi /etc/apache2/mods-available/jk.confl

JkWorkersFile /etc/libapache2-mod-jk/workers.properties
Update the  worker properties file for our appServer: 
# Define 1 real worker named ajp13
# Set properties for worker named ajp13 to use ajp13 protocol,
# and run on port 8009
# Enable load balancer for this worker
Configure url forwarding in apache to tomcat.Add the following lines in you apache virtualhost to forward requests to tomcat:
sudo vi /etc/apache2/sites-available/default
<VirtualHost *:80>
# Send everything for appA and aapB  to worker ajp13
JkMount /appA ajp13
JkMount /appA/* ajp13
JkMount /appB ajp13
JkMount /appB/* ajp13
sudo vi /etc/apache2/sites-available/default-ssl
<VirtualHost _default_:443>
# Send everything for appA and aapB  to worker ajp13
JkMount /appA ajp13
JkMount /appA/* ajp13
JkMount /appB ajp13
JkMount /appB/* ajp13
Restart the tomcat(appServer) and apache server.
VI) OpenLdap set up
Sudo Installaton 
sudo apt-get update
sudo apt-get install slapd ldap-utils
You will be asked to enter and confirm an administrator password for the administrator LDAP account.
When the installation is complete, we actually need to reconfigure the LDAP package. Type the following to bring up the package configuration tool:
sudo dpkg-reconfigure slapd
You will be asked a series of questions about how you'd like to configure the software.
There are no set rules for how to configure this. If you have an actual domain name on this server, you can use that. Otherwise, use whatever you'd like.
In this tutorial, we will call it kuntal.example.org (as we have set our doamin name earlier).
We will be administering LDAP through a web interface called PHPldapadmin. 
Install it with this command:
sudo apt-get install phpldapadmin
Now navaigate your browser :
Password → {You created during openldap installation} (ldapadmin) for this tutorial.
Now create some groups and users along with their password.

What is Shibboleth?
Simply put, Shibboleth is a federated identity management system for single sign-on on the web. Let’s break it down:
Single Sign on – You log-on to one resource and when you visit the next resource you are automatically signed on. Why is this important? No need to re-authenticate users as they move from resource to resource.
Identity Management – The purpose of Shibboleth is to manage user identities, and their key attributes of an identity such as name, email, role, whether you are authenticated and who authenticated you.
Federated – This means it works “across domains” For example freemail.com can accept users from itself, as well as gmail.com. Why is this important? You don’t have to host the service under your domain to benefit from single sign-on.
Why Shibboleth?
There are a lot of good reasons for doing this:
  • Your users won’t get carpel-tunnel from typing in their password 20x a day. If you’re an organization, your users will like the benefits of Single sign-on. Once they authenticate against your identity provider they will be automatically logged on to the various service providers.
  • Your users’ passwords aren’t being passed around like a joint at a 70′s party. Service providers don’t authenticate users. They request the identity provider do that for them. As a result your password is never seen or stored by the service providers. If you’re writing an application which will be a service provider, you don’t need to worry about storing passwords.
  • Safer than “sign-on with Facebook” or “login with Twitter.” You control your user’s identities, not some flighty start-up. IT departments rejoice.
  • Easy to “Shibbolize” Adding shibboleth support to any application is relatively simple, just figure out what to do with the “accepted” attributes you receive from your installed service provider and run with it.

Set up and Configuration

Shibboleth Set Up
1.  Make directory for download
Move to sso directory 
cd /home/kuntal/Kuntal/sso
 Make a directory shibboleth
mkdir /home/kuntal/Kuntal/sso/shibboleth
and move into it
cd /home/kuntal/Kuntal/sso/shibboleth
Now execute the following commands one by one:
Note: You might get pre-check error. So make sure you have g++ , boost header version install. Otherwise install it with → 
sudo apt-get install g++
sudo apt-get install libboost-all-dev
sudo apt-get install libssl-dev
sudo apt-get install libcurl4-openssl-dev
sudo apt-get install apache2-prefork-dev
2.  Download shibboleth
Dowanload SP:
wget http://shibboleth.net/downloads/service-provider/latest/shibboleth-sp-2.5.3.tar.gz
Download IDP:
wget http://shibboleth.net/downloads/identity-provider/latest/shibboleth-identityprovider-2.4.0-bin.tar.gz
Download OpenSaml:
wget http://shibboleth.net/downloads/c++-opensaml/latest/opensaml-2.5.3.tar.gz
Download log4shib
wget http://shibboleth.net/downloads/log4shib/latest/log4shib-1.0.8.tar.gz
Download xml tooling:
wget http://shibboleth.net/downloads/c++-opensaml/latest/xmltooling-1.5.3.tar.gz
Download xml security
wget http://www.apache.org/dyn/closer.cgi?path=/santuario/c-library/xml-security-c-1.7.2.tar.gz
Download Xerces
wget http://apache.arvixe.com//xerces/c/3/sources/xerces-c-3.1.1.tar.gz
3.  Extract all  tar.gz file with --> 
 tar -xzvf command
4.  Installing Shibboleth IDP
Move to the extracted shibboleth IDP directory.
cd /home/kuntal/Kuntal/sso/shibboleth/shibboleth-identityprovider-2.4.0
Execute (Make sure you have apache ant configure on your machine with ANT_HOME set properly)
It will ask you for the directory where you want to install your shibboleth IDP
Where the Shibboleth Identity Provider software should be installed?
Enter the following:
5.  After Installation of IDP:
Copy the idp.war file from ~/sso/shibboleth-idp/war, paste it to IDP tomcat Server webapp directory
cp /home/kuntal/Kuntal/sso/shibboleth-idp/war/idp.war /home/kuntal/Kuntal/sso/apache-tomcat-6.0.39/webapps
Update the server.xml of the IDP tomcat server.
Listing 1. Tomcat IDPServer’s server.xml
<Connector port="8443"
          keystorePass="changeit" />
Make a directory name endorsed in IDP server home.Then copy paste the xml related libraries from endorsed directory of shibboleth IDP home installation.
/home/kuntal/Kuntal/sso/shibboleth-idp/lib to IDP server home /home/kuntal/Kuntal/sso/apache-tomcat-6.0.39/endorsed. 
Also copy the tomcat-dta-ssl.jar provided in source code to IDP Server_HOME/lib directory.
6.  Now restart tomcat IDP server.
And navigate the browser to https://kuntal.example.org:8443/idp/status
You will see some IDP and system related information.
7.  Installing Shibboleth SP:
Move to the  sso/shibboleth directory
cd /home/kuntal/Kuntal/sso/shibboleth/
Now execute the following commands one by one:

Move to log4shib directory and execute:
./configure --disable-static --disable-doxygen --prefix=/home/kuntal/Kuntal/sso/shibboleth-sp && make && sudo make install

Move to xerces directory and execute:
./configure --prefix=/home/kuntal/Kuntal/sso/shibboleth-sp && make && sudo make install
Move to xmlsecurity directory and execute:
./configure --without-xalan --disable-static --with-xerces=/home/kuntal/Kuntal/sso/shibboleth-sp --prefix=/home/kuntal/Kuntal/sso/shibboleth-sp && make && sudo make install

Move to xmltooling directory and execute:
./configure --with-log4shib=/home/kuntal/Kuntal/sso/shibboleth-sp --prefix=/home/kuntal/Kuntal/sso/shibboleth-sp -C && make && sudo make install 

Move to opensaml directory and execute:
./configure --prefix=/home/kuntal/Kuntal/sso/shibboleth-sp --with-log4shib=/home/kuntal/Kuntal/sso/shibboleth-sp -C && make && sudo make install

Move to shibboleth-sp directory and execute:
./configure --with-saml=/home/kuntal/Kuntal/sso/shibboleth-sp --enable-apache-22 --with-log4shib=/home/kuntal/Kuntal/sso/shibboleth-sp --with-xmltooling=/home/kuntal/Kuntal/sso/shibboleth-sp --prefix=/home/kuntal/Kuntal/sso/shibboleth-sp -C && make && sudo make install
Note: In Ubuntu you can also install Shibboleth Service provider using:
sudo apt-get install libapache2-mod-shib2 shibboleth-sp2-schemas
But this installation sometime doesn’t work properly in various version of Ubuntu.
8.  After SP Installation:
Copy the contents of the shibd startup script to /etc/init.d/shibd:
sudo touch /etc/init.d/shibd
 Now update the shibd with the following:

sudo vi /etc/init.d/shibd
Execute these commands to activate shibd : 
sudo chmod +x /etc/init.d/shibd

Integrating Shibboleth SP with Apache
Configure Apache2 to use the Shibboleth module:
echo "export LD_LIBRARY_PATH=/home/kuntal/Kuntal/sso/shibboleth-sp/lib" | sudo tee -a /etc/apache2/envvars
echo "LoadModule mod_shib /home/kuntal/Kuntal/sso/shibboleth-sp/lib/shibboleth/mod_shib_22.so" | sudo tee -a /etc/apache2/mods-available/shib2.load
echo "UseCanonicalName On" | sudo tee -a /etc/apache2/httpd.conf
Create a shib2.conf 
sudo vi /etc/apache2/mods-available/shib2.conf
Enable the shib2 module in Apache and restart Apache: 
sudo a2enmod shib2
sudo /etc/init.d/apache2 restart
Open up a web browser and point to your site with the following Shibboleth path: 
Verify that you see this message: 
A valid session was not found.

Flows and Configuration
Shibboleth has two major halves: an identity provider (IdP), and a service provider (SP). The identity provider supplies information about users to services, and the service provider gathers information about users to protect resources. In the typical use case, a web browser accesses a protected resource, authenticates at their identity provider, and ends up back at the resource logged in.
1.  User Accesses Protected Resource
A user tries to access a protected resource, causing the SP to intercept the request. The resource locations to protect can be defined in the web server configuration itself, such as shibd.conf, or in shibboleth2.xml (or a separate file) using the <RequestMap>.
2.  SP Determines IdP and Issues Authentication Request
The SP will select a SessionInitiator to use based on this protection configuration, which in turn is responsible for determining which IdP the user will be referred to and what protocol to use. The providers signal their profile preferences to one another through the exchange of SAML metadata.
The process of determining the IdP to use is called IdP Discovery and can include a combination of configuration options, various web-based interactions, cookies, and other techniques. A SessionInitiator might supply a text entry box, refer the user to a locally or remotely deployed discovery service (DS), or select a fixed IdP based on the resource requested.
3.  User Authenticates to the IdP
An authentication request is issued by the SP to the IdP as a result of the previous step. The format of this request depends on the protocol and binding/profile selected by the SP. The authentication request is passed through the browser, and the client is redirected (via GET or POST) to an endpoint at the IdP typically called a "Single Sign-On Service".
The IdP examines the request and decides how it would like to authenticate the user based on rules established for the SP in relying-party.xml and authentication in general in <LoginHandler> and login.config. The user is redirected to the selected login handler, authenticates (or tries to) using the method selected, and eventually control passes back to the profile handler with their username set.
4.  IdP Issues Response to SP
The IdP now uses the principal's name, the SP, and the protocol and binding/profile selected to decide what information to send the SP and how to package it.
First, the IdP gathers a set of attributes for the user using the attribute resolver. It collects user data from all the backend sources, transforms it if necessary, and attaches encoders to each attribute.
These attributes are passed through the attribute filter, which may pare down the information to be included in the response. The set of attributes released most often depends on the SP and the principal. This protects the user's privacy. The resulting information could be as little as "someone authenticated successfully", or reveal any attribute you can imagine.
The user's information is packaged into a form suitable for the eventual response using the encoders attached earlier, typically in a SAML assertion. This assertion may be signed with the IdP's key and, in the case of a SAML 2.0 assertion, encrypted with the SP's key for security and privacy. The assertion (or a reference to it called an artifact) is placed into a response that is passed through the client browser for delivery back to the SP to an endpoint called anAssertion Consumer Service.
5.  Back to the SP
The browser delivers the response from the IdP to an Assertion Consumer Service endpoint at the SP. The ACS implementation decodes the message, decrypts the assertion if necessary, and performs a variety of security checks. If everything is in order, then the SP will create a new user session after extracting attributes and other information from the message. Attributes are translated into a cacheable form using the SP's AttributeExtractor, passed through an AttributeFilter, and cached in the new session along with other relevant information.
Once the session is created, the SP determines where to send the browser by examining the "relay state" information returned by the IdP, if any.
6.  Back to the Protected Resource
In the final step, the browser is redirected to the protected resource accessed in Step 1, but this time the access occurs in the context of a session stored within the SP's SessionCache.
Integrating Shibboleth IDP and SP
SP Configuration: All the configuration files of Shibboleth SP are located in SP_HOME/etc/shibboleth → /home/kuntal/Kuntal/sso/shibboleth-sp/etc/shibboleth

1.  attribute-map.xml: The SP translates attributes that it receives on the wire, typically from SAML assertions, using an attribute extractor, typically via the attribute-map.xmlconfiguraton file. The file contains a series of mapping rules that reference the "on the wire" representation and connect it to a more convenient short-hand.

Listing 2. attribute-map.xml
<Attribute name="urn:mace:dir:attribute-def:givenName" id="givenName"/>
<Attribute name="urn:mace:dir:attribute-def:uid" id="uid"/>
2.  attribute-policy.xml: The <AttributeFilter> element is used to configure plugins that filter incoming attributes to prevent applications protected by an SP from seeing data that violates whatever policies the filter implements.
Listing 3. attribute-policy.xml
<afp:AttributeRule attributeID="uid">
<afp:PermitValueRule xsi:type="ANY"/>
3.  shibboleth2.xml: Most of the native service provider's configuration options are found in shibboleth2.xml, located in the SP's main configuration directory. The primary configuration file consists of an <SPConfig> element that contains one each of several other top-level elements, each representing a category of SP configuration, and optional extensions.
The <MetadataProvider> element configures a source of Metadata for the SP to use. Generally used only within the shibd service.
Unlike other configuration files which describe how the SP will behave, the metadata loaded by the SP describes the IdPs it wants to interact with. Each application determines the set of partner sites to trust by loading their metadata (or providing some kind of dynamic mechanism to do so). 
Listing 4. shibboleth2.xml
<MetadataProvider type="XML" uri="https://shibboleth.example.org:8443/idp/shibboleth" backingFilePath="idp92-metadata.xml" reloadInterval="7200"/>
IDP Configuration: All the configuartion files of IDP are located in IDP_HOME/conf directory
1.  attribute-filter.xml: An attribute filter policy describes which attributes are sent to a service provider.
Listing 5. attribute-filter.xml
<afp:AttributeRule attributeID="uid">
<afp:PermitValueRule xsi:type="basic:ANY" />
2.  attribute-resolver.xml:An attribute passes through four main steps from source system to release to an SP: it's pulled from the system of record, massaged within the provider, given a set of protocol-specific encoders, and then filtered for release. Every attribute has a unique attribute ID which is used to refer to it consistently through this process.

Listing 6. attribute-resolver.xml
<resolver:AttributeDefinition xsi:type="ad:Simple" id="uid" sourceAttributeID="uid">
 <resolver:Dependency ref="myLDAP" />
 <resolver:AttributeEncoder xsi:type="enc:SAML1String" name="urn:mace:dir:attribute-def:uid" />
<resolver:AttributeEncoder xsi:type="enc:SAML2String" name="urn:oid:0.9.2342.19200300.100.1.1" friendlyName="uid" </resolver:AttributeDefinition>
3.  handler.xml: This file contains all the profile handlers and login handlers for the IDP.The authentication handler supports authenticating users with a username  and password. This authentication is performed through the Java Authentication and Authorization Service (JAAS).
Comment out Remote User Login Handler  and uncomment  Username/password login handler and then update it:
Listing 7. handler.xml 
<ph:LoginHandler xsi:type="ph:UsernamePassword" 
                  jaasConfigurationLocation="file:///home/kuntal/Kuntal/sso/shibboleth-idp/conf/login.config"> <ph:AuthenticationMethod>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</ph:AuthenticationMethod>
4.  logging.xml: Enable debug for IDP logs and Open SAML Messages
 <!-- Logs IdP,  OpenSAML, messages -->
 <logger name="edu.internet2.middleware.shibboleth" level="DEBUG"/>
 <logger name="PROTOCOL_MESSAGE" level="DEBUG" />
5.  login.config: This is the JAAS configuration file used by the Shibboleth IDP.

Listing 8. login.config 
ShibUserPassAuth {
      edu.vt.middleware.ldap.jaas.LdapLoginModule required
6.  relying party.xml: The configuration for communicating with relying parties.In nearly all cases an IdP communicates with a service provider. However, in some more advanced cases an IdP may communicate with other entities (like other IdPs). The IdP configuration uses the generic term relying party to describe any peer with which it communicates. A service provider, then, is simply the most common type of relying party.
The IdP recognizes three classifications of relying parties:
anonymous - a relying party for which the IdP has no metadata
default - a relying party for which the IdP does have metadata but for which there is no specific configuration
specified - a relying party for which the IdP has metadata and a specific configuration

Listing 9. relying-party.xml
<metadata:MetadataProvider id="ShibbolethMetadata" xsi:type="metadata:ChainingMetadataProvider">
 <!-- Load the IdP's own metadata.  This is necessary for artifact support. -->
<metadata:MetadataProvider id="IdPMD" xsi:type="metadata:FilesystemMetadataProvider"
 metadataFile="/home/kuntal/Kuntal/sso/shibboleth-idp/metadata/idp-metadata.xml"  maxRefreshDelay="P1D" />

<!-- Load the SP's metadata.  -->
<metadata:MetadataProvider id="SPMD" xsi:type="metadata:FilesystemMetadataProvider"
7.  IDP metadata location: IDP_HOME/metadata -> /home/kuntal/Kuntal/sso/shibboleth-idp/metadata
You will find a idp-meta.xml file inside it. But you also need to put SP metadata in it.
Navigate your browser to:
You will get a service providers default metadata template.Rename it to sp-metadata.xml and place it in /home/kuntal/Kuntal/sso/shibboleth-idp/metadata directory

Now update idp-metadata.xml:
Now change the Location value from AttributeService,ArtifactResolutionService,SingleLogoutService, SingleSignOnService tag .
Previous:  Location="/idp/profile/SAML2/SOAP/SLO" 
Modified:  Location="https://kuntal.example.org:8443/idp/profile/SAML2/SOAP/SLO" 
Now update sp-metadata.xml:
Now change the Location value from ArtifactResolutionService,SingleLogoutService, AssertionConsumerService tag .
Previous:  Location="/Shibboleth.sso/Shibboleth/SSO” 
Modified:  Location="https://kuntal.example.org/Shibboleth.sso/Shibboleth/SSO"

Deploy Applications on App-Server
Capturing user-attributes from Shibboleth IDP :
Before capturing meta-attributes from IDP, first download the appA. war and appB. war from the source code of this tutorial  and deploy it appServer as mentioned in Part 1 of this tutorial series.
From Sevlet/Jsp you can access the attributes using request.getAttribute(attr_name)

But to get this value you have to do the following:

1. Enable attribute prefix in Shibboleth SP shibboleth2.xml file in <ApplicationDefault> tag->    attributePrefix="AJP_"
2. Enable proxy_ajp module:
sudo a2enmod proxy proxy_ajp

3.  Add the following in httpd.conf
ProxyPass /appA ajp://localhost:8090/appA
ProxyPass /appB ajp://localhost:8090/appB

4.  Then, restart apache server and shibd.
sudo /etc/init.d/apache2 restart
sudo /etc/init.d/shibd restart
Also you can get information through header.
For getting shibbolethes attribute values through header you have to enable the header inside Location tag of shib2.conf file as shown below->  ShibUseHeaders On
Configuring applications resources with Shibboleth SP:
Add the following in shib2.conf for applications Access Control.

Listing 10. shib2.conf 
<Location /appA/*>
  AuthType shibboleth
  ShibRequestSetting requireSession 1
   require valid-user
<Location /appB/*>
  AuthType shibboleth
  ShibRequestSetting requireSession 1
  ShibUseHeaders On
  require valid-user
Note: If you want to make certain application only accessible to specific user do this as shown below-
Listing 11. shib2.conf – user based access
<Location /appA/*>
  AuthType shibboleth
  ShibRequestSetting requireSession 1
   require user kganguly
user field will try to retrieve value from REMOTE_USER and match with kganguly. Other user will receive Access denied page.
Validation and Testing:
Before doing the testing do the following:
1. Restart tomcat IDP Server and appServer (with applications deployed in it)
2. Restart apache server and shibd.
It will be automatically taken to Shibboleth IDP login page as shown below:

After successful authentication at the IDP, you will be redirected to your application resource and you will see the below screen:

Tuning and Common Issues

1. Session Timeout: Session can be timeout can be done on both IDP and SP.
SP session timeout configuration: Configure the Session tag in shibboleth2.xml. 
 <Sessions lifetime="3600" timeout="60">
IDP session timeout configuration: Configure SessionManger in internal.xml file-based
 <bean id="shibboleth.SessionManager" >
        <constructor-arg ref="shibboleth.StorageService"/>
        <constructor-arg value="300" type="long"/>

2. Logout: To apply Shibboleth Logout use the following url /Shibboleth.sso/Logout
 In this tutorial for applications (appA and appB)
<form action="/Shibboleth.sso/Logout" method="post">
<input type="submit" value="Logout" >

3. Browser not Redirecting properly or infinite looping: The browser looping after successful authentication at the IDP end happens because SP tries to create new session and send user for authentication repeatedly to the IDP. And this continues in browser as loop.
Reason: Shibboleth SP not receiving the attribute mention in REMOTE_USER of <ApplicationDefaults > tag in shibboleth2.xml. Enable the Debug mode in IDP logs and make sure the attribute that you have mentioned for REMOTE_USER are coming properly from IDP side through SAML message. Make sure you are using same namespace for the attribute at IDP and SP end. Also the encoder and decoder are correct at both the IDP & SP.
Also make sure the attribute that you are using as NameID has value in SAML response. Most often we make transient Id as nameid, but it has no value .Hence IDP eliminates it in SAML response. So make a attribute nameid, which has proper value like eppn or cn or (given name  as in case of this tutorial)
<resolver:AttributeDefinition xsi:type="ad:Simple" id="givenName" sourceAttributeID="givenName">
 <resolver:Dependency ref="myLDAP" />
<resolver:AttributeEncoder xsi:type="enc:SAML2StringNameID" nameFormat="urn:oasis:names:tc:SAML:2.0:nameid-format:unspecified"/>
Also make sure the sp metadata at the IDP and SP are up to date. Any mismatch in the metadata at both side can case looping.

4. No Peer Endpoint available: Make sure your AssertionConsumerServiceURL is coming from SP to the IDP through saml authentication Request is right. Its a error from the SP side but you might see it on IDP. Debug the log for OpenSaml message Request Response to check assertion consumer service url coming from SP is matching with the AssertionConsumerService Location mentioned in SP metadata.xml file that IDP is using.

In this tutorial you just learn how easily you can develop a sigle sign on based identity management system between multiple applications with Shibboleth Identity Provider and Service Provider.In the  Part3 of this tutorial series,you will learn to develop identity management system with CAAS.
About the authors 

Kuntal Ganguly :
Software Engineer having 4 year experience on Java platform and Big Data. Has expertise in using a wide range of open source and commercial product (Solr, Hadoop, Hbase, Hive, Pig, Storm, Spark, R, Pentaho ETL, KafkaMQ,  Redis, RocksDB, OracleAQ, Weblogic ) .Currently associated as a Big Data and Search Analyst at ARC Document Solution Ltd. 
Partha Goswami:
Software Engineer having 4 year experience on Java platform and Oracle Fusion Middleware. Has expertise in using a wide range of open source and commercial tools (Websphere, Oracle SOA Suite, BPM, Mule ESB, RAD, Active MQ, Android, Birt  and DB2). Currently associated as a J2EE developer at Cognizant Technology Solution.

The Integration Zone is brought to you in partnership with CA Technologies.  Use CA Live API Creator to quickly create complete application backends, with secure APIs and robust application logic, in an easy to use interface.

java,opinion,enterprise-integration,security,integration,single sign on,identity management,shibboleth

The best of DZone straight to your inbox.

Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}