03 Dec 2018 SSO with SAML Authentication Using Shibboleth IDP
Posted
Introduction:
The objective of this article is to achieve SSO with SAML authentication in AEM involving Single identity provider(IDP). Here we are using Shibboleth as IDP.
This article includes setting up Shibboleth IDP , integrating with ApacheDs(Directory Server) followed by integration with AEM.
Little bit background on SAML – Secure Assertion Markup Language
SAML is a secure xml based communication language which can share identities between multiple organisation and applications.
Many Large Enterprises/organisations providing multiple web/mobile applications require users to access it securely . These organisations already know users identity as they would have logged in to the system and their identity is stored in the enterprise active directory. I t makes sense to use this information to login to other applications which out having to re-login to each of these applications. SAML provides secure way of achieving this single sign on.
For SAML to work there are 3 entities involved, principal i.e., users , identity provider (maintains directory of user and authentication mechanism), service provider which hosts target website, application or service and serves the request.
SAML SSO works by transferring the user’s identity from the identity provider to the service provider. This is done through an exchange of digitally signed XML documents.
Consider the following scenario: A user is logged into a system that acts as an identity provider. The user wants to log in to a remote application hosted on the service provider. The following happens:
- The user accesses the remote application and the application loads.
- The application identifies the user’s origin (by application subdomain, user IP address, or similar) and redirects the user to the identity provider, asking for authentication. This is the authentication request.
- The user either has an existing active browser session with the identity provider or establishes one by logging into the identity provider.
- The identity provider builds the authentication response in the form of an XML-document containing the user’s username or email address, signs it using an X.509 certificate, and posts this information to the service provider.
- The service provider, which already knows the identity provider and has a certificate fingerprint, retrieves the authentication response and validates it using the certificate fingerprint.
- The identity of the user is established and the user is provided with app access.
Setting up the Environment
Softwares used for the setup
The binaries used are mentioned below.
Software | Version | Downloaded from |
Shibboleth IDP | 2.4.4 | |
Tomcat (App server for IDP) | apache-tomcat-8.5.35 | |
Apache Directory Service Specific to OS | ApacheDS-2.0 | |
Apache Directory Studio(Client to connect to ApacheDS) | Apache Directory Studio-2.0 | |
JDK | JDK 1.8 | https://www.oracle.com/technetwork/pt/java/javase/downloads/index.html |
1. Installation and Configuration of Apache DS and Apache Directory Studio(LDAP server and Client).
We need to setup LDAP sever, where we can create users and groups. Here we are using Apache DS.
Follow the installation instructions from ApacheDS during installation also install Apache Directory Studio, a client to connect to Apache DS.
Below are the steps to create connection and users in Apache DS using Apache Directory Studio.
- Open the Apache Directory, to create connection to ApacheDS. The bottom left corner shows all of the LDAP connections. If the view is empty, meaning a connection still needs to be specified.
- To create a new connection click the
New Connection button.
- In the wizard’s first page enter a connection name as well as the hostname and the port of the LDAP server. To check the connection parameter you entered you may click to Check Network Parameter. Click Next when done.
Here is a list of common directory servers and the ports they use by default:Directory Server
Default Port
Apache Directory Server
10389
OpenDS
1389
OpenLDAP, Fedora, Sun, Active Directory
389
- In the wizard’s second page select the authentication method. You can choose the simple bind method and enter your bind DN or user and bind password. To check the authentication parameter you entered you may click to Check Authentication. Click Finish when done.
- Here is a list of common directory servers and the administrator’s bind DN and password they use by default:
Directory Server
Default Bind DN
Default Bind Password
Apache Directory Server
uid=admin,ou=system
secret
OpenDS, Sun, Fedora
cn=Directory Manager
specified at setup
OpenLDAP
specified at setup, see slapd.conf
specified at setup, see slapd.conf
- Observe that the Connections view now shows the created connection.
- Next step is to create new users. If the connection is successfully established, you should see an outline of the Directory Information Tree (DIT) in the LDAP Browser view. In theLDAP Browser view, drill down to the ou=users node, as shown.
- Right-click on the ou=users node and select New Entry. The New Entry wizard appears.
- In the Entry Creation Method pane, you do not need to change any settings. Click Next.
- In the Object Classes pane, select inetOrgPerson from the list of Available object classes on the left and then click Add to populate the list of selected object classes. Click Next. Note: The object classes for all objects in the directory form a class hierarchy. The classes “top” and “alias” are at the root of the hierarchy. For example, the “organizationalPerson” object class is a subclass of the “Person” object class, which in turn is a subclass of “top”. When creating a new LDAP entry, you must always specify all of the object classes to which the new entry belongs. Because many directories do not support object class subclassing, you also should always include all of the superclasses of the entry. For example, for an “inetOrgPerson” object, you should list in its object classes the “organizationalPerson”, “person”, and “top” classes
- Create a new user entry in the Distinguished Name pane, complete the RDN(Relative Domain Name)field, putting uid in front and userID after the equals sign. Click Next.
- Now fill in the remaining mandatory attributes in the Attributes pane. Set the cn (common name) attribute to John Doe and the sn (surname) attribute to Doe. Click Finish.
- Add a userPassword attribute to the user entry.
- In the LDAP Browser view, you should now be able to see a new node, uid=jdoe. Select the uid=jdoenode. Now, right-click in the Entry Editor view and select New Attribute. The New Attribute wizard appears. From the Attribute type drop-down list, select userPassword. Click Finish.
- The Password Editor dialog appears. In the Enter New Password field, enter the password, “secret”. Click Ok.
- To add more users, repeat steps 7 to 14.
2. Installation of Shibboleth IDP
Unzip the downloaded (shibboleth-identityprovider-2.4.4-bin.zip) binary and run the install.bat file / install.sh. The installation creates the IdP’s entity ID, initial metadata, a basic set of IdP configuration files and a key pair of self-signed certificate used for signing/encryption.
Remember the password given during installation. IDP keystore is generated during installation. This password will be used during SSL configuration of tomcat.
Structure of the folder under Shibboleth installation directory
Structure of the credentials folder holding certificate and keys
The installed path configured will be used to update all the configuration xml for the path.
Default path is \opt\shibboleth-idp.The domain name entered during installation should be set in the host file
Ex: 127.0.0.1 http://www.blogsaml.com
3. Installation and configure Tomcat
- Unzip and install tomcat 8.5 into any directory and set CATALINA_HOME in environment variables to the installation directory of tomcat
- Configure server.xml in tomcat under the path <TOMCAT_HOME>/conf to enable SSL as below. Here JSSE implementation is used for SSL.
<Connector port="8443" protocol="org.apache.coyote.http11.Http11NioProtocol" maxPostSize="100000"
HttpHeaderSize="1048576"
maxThreads="150"
SSLEnabled="true"
scheme="https"
secure="true"
clientAuth="want"
sslProtocol="TLS"
keystoreFile="/Users/abc/shibboleth-installation/credentials/idp.jks"
keystorePass="test123"
trustManagerClassName="net.shibboleth.utilities.ssl.TrustAnyCertificate" />- Configure keystore to point to IDP keystore generated during Shibboleth IDP installation
- Make sure the SSL port is properly set, we can set it to 8443.
- Copy “idp.war” from <IDP install folder>/war/idp.war to <TOMCAT_HOME>/webapps
- If you see below exception in catalina.out, download trustany-ssl-1.0.0.jar and place it under <TOMCAT_HOME>/lib
SEVERE [main] org.apache.catalina.core.StandardService.initInternal Failed to initialize connector [Connector[HTTP/1.1-8443]]
org.apache.catalina.LifecycleException: Failed to initialize component [Connector[HTTP/Caused by: java.lang.IllegalArgumentException: net.shibboleth.utilities.ssl.TrustAnyCertificate
Caused by: java.lang.ClassNotFoundException: net.shibboleth.utilities.ssl.TrustAnyCertificate
at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at org.apache.tomcat.util.net.jsse.JSSEUtil.getTrustManagers(JSSEUtil.java:312)
at org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:113)
... 20 more4. Configuring Shibboleth IDP
When Shibboleth is installed below set of files will be created under <IDP install folder>/conf , which needs to be configured accordingly to get SAML authentication and SSO working.
Follow below steps
- Modify <IDP installed folder>/conf/login.config, make sure the path to login.conf is properly configured to point to LDAP server
ShibUserPassAuth {
edu.vt.middleware.ldap.jaas.LdapLoginModule required
ldapUrl="ldap://www.blogsaml.com:10389"
base="ou=users,ou=system"
bindDn="uid=admin,ou=system"
bindCredential="secret"
ssl="false"
tls="false"
userField="uid"
userFilter="uid={0}";
};- We need to modify attribute-resolver.xml to add definition of attributes(resolver:AttributeDefinition) for uid, group and mail, these are the user attributes to be sent across to service provider from LDAP once authenticated. Also we need to specify LDAP connection string(resolver:DataConnector) for the IDP to connect in order to get the user details.
<resolver:AttributeDefinition id="transientId" xsi:type="ad:TransientId">
<resolver:AttributeEncoder xsi:type="enc:SAML1StringNameIdentifier" nameFormat="urn:mace:shibboleth:1.0:nameIdentifier"/>
<resolver:AttributeEncoder xsi:type="enc:SAML2StringNameID" nameFormat="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"/>
</resolver:AttributeDefinition>
<resolver:AttributeDefinition id="uid" xsi:type="ad:Simple" xmlns="urn:mace:shibboleth:2.0:resolver:ad"
sourceAttributeID="uid">
<resolver:Dependency ref="myLDAP" />
<resolver:AttributeEncoder xsi:type="SAML2String" xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
name="uid" friendlyName="uid" />
</resolver:AttributeDefinition>
<resolver:AttributeDefinition xsi:type="ad:Simple" xmlns="urn:mace:shibboleth:2.0:resolver:ad" id="group"
sourceAttributeID="businessCategory">
<resolver:Dependency ref="myLDAP" />
<resolver:AttributeEncoder xsi:type="enc:SAML2String" name="group" friendlyName="group" />
</resolver:AttributeDefinition>
<resolver:AttributeDefinition xsi:type="ad:Simple" xmlns="urn:mace:shibboleth:2.0:resolver:ad" id="mail"
sourceAttributeID="mail">
<resolver:Dependency ref="myLDAP" />
<resolver:AttributeEncoder xsi:type="enc:SAML2String" name="mail" friendlyName="mail" />
</resolver:AttributeDefinition><resolver:DataConnector id="myLDAP" xsi:type="dc:LDAPDirectory"
ldapURL="ldap://www.blogsaml.com:10389"
baseDN="ou=users,ou=system"
principal="uid=admin,ou=system"
principalCredential="secret">
<dc:FilterTemplate>
<![CDATA[
(uid=$requestContext.principalName)
]]>
</dc:FilterTemplate>
</resolver:DataConnector>- Modify <IDP installed folder>/conf/attribute-filter.xml to add Attribute rule for uid,group and mail. Attribute filter specifies the attributes that will be sent across to service provider.
<afp:AttributeRule attributeID="uid">
<afp:PermitValueRule xsi:type="basic:ANY" />
</afp:AttributeRule>
<afp:AttributeRule attributeID="group">
<afp:PermitValueRule xsi:type="basic:ANY" />
</afp:AttributeRule>
<afp:AttributeRule attributeID="mail">
<afp:PermitValueRule xsi:type="basic:ANY" />
</afp:AttributeRule>
- Update ProfileHandlers and Login Handlers in <IDP installed folder>/conf/handler.xml as below. Login Handler are required to know details of LDAP Server. Point to right location of login.conf. Remove all the entries for authentication in LoginHandler except “UsernamePassword” and “PreviousSession.”
- Modify <IDP installed folder>/conf/logging.xml for detail debug trace.
- Add the metadata file adobecq.xml at <IDP installed folder>/metadata/ , which provides informations about service provider, the certificates used for signing SAML message and where to post the SAML response once user is authenticated and where to redirect on logout. Configure the Entity ID to match the Service provider entity ID given in SAML 2 authentication handler configuration in AEM config. Configure Location in AssertionConsumerService to match to AEM intercept path (default path) in SAML 2 authentication handler configuration. This path should end with saml_login .
Sample xml
<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" entityID="https://www.blogsaml.com">
<md:SPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol urn:oasis:names:tc:SAML:1.1:protocol">
<md:KeyDescriptor>
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#" Id="SPInfo">
<ds:X509Data>
<ds:X509Certificate>
MIIEdzCCA1+gAwIBAgIJAPswGGW+b631MA0GCSqGSIb3DQEBBQUAMIGDMQswCQYD
VQQGEwJVUzELMAkGA1UECBMCTUExDjAMBgNVBAcTBUFjdG9uMQ4wDAYDVQQKEwVB
ZG9iZTESMBAGA1UECxMJTWFya2V0aW5nMQ8wDQYDVQQDEwZIYXNzYW4xIjAgBgkq
hkiG9w0BCQEWE3NhbXBsZUBibG9nc2FtbC5jb20wHhcNMTQwNTIzMTkzODI1WhcN
MTcwNTIyMTkzODI1WjCBgzELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAk1BMQ4wDAYD
VQQHEwVBY3RvbjEOMAwGA1UEChMFQWRvYmUxEjAQBgNVBAsTCU1hcmtldGluZzEP
MA0GA1UEAxMGSGFzc2FuMSIwIAYJKoZIhvcNAQkBFhNzYW1wbGVAYmxvZ3NhbWwu
Y29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsW8NAHsIvl4EdEu0
0eZHuSYOAFLDZa0EQzf5+QDE179uHkqFIYpgdSJO3qj3HNKqlU/vnZNhQBJ2tRrc
BjI7pWQO/G9f+7pQKke9QVU88IDnmmGknlCTiaKLv4p68XHR4AeTI2tfulYpURa+
V5onIxXoyXqubrSxTb0zWVZy9iZmpPA2gCkH3Yzi/TM+yxz5A7q/Vh4pYm3+xqQS
gb1h5CFpA3YWlfSw2ONvNKlx9vJjfC+UCFxzNzbEF7f5u/c2zdKs72b70W8CnwTg
ny+C0qEDLKNYStVag8AUau9SmyXoKSShvHfZOGNW0ad1n44dD9TLCTKTpG1DloWI
yugtzwIDAQABo4HrMIHoMB0GA1UdDgQWBBT6Ve57XbEy+G+EzQTE+o8rzEiimzCB
uAYDVR0jBIGwMIGtgBT6Ve57XbEy+G+EzQTE+o8rzEiim6GBiaSBhjCBgzELMAkG
A1UEBhMCVVMxCzAJBgNVBAgTAk1BMQ4wDAYDVQQHEwVBY3RvbjEOMAwGA1UEChMF
QWRvYmUxEjAQBgNVBAsTCU1hcmtldGluZzEPMA0GA1UEAxMGSGFzc2FuMSIwIAYJ
KoZIhvcNAQkBFhNzYW1wbGVAYmxvZ3NhbWwuY29tggkA+zAYZb5vrfUwDAYDVR0T
BAUwAwEB/zANBgkqhkiG9w0BAQUFAAOCAQEATJi8KCGnNM6lVX8x+GBhm3q0VdF+
VIAvYXJ4TqP3DGSUFr2ETt187cQ3ZtJsU+U5mQ8NX6DRJ7QVZjKPe/6vRltVlsvR
z+b8vjXlWVWo6Zjcd96MQibESEutzLlwfQBq3A3azzqUmtEpA2woXzhV5XXvAsqt
HsPYgcM9mZNO+FS3pDkOEdfyQuG4nUa0s2jx/gIYtqcMJqTK5d3c1nAaUhLEVuYr
Upm6t+eL0/Yw4hrTjP3kEQO6g5ABsv9ew7iPs7G1RMm5BJErHyAHvgAeP/NZD/H6
C4fnnHXKhR7wbpxu9VipDIXQBmblPSvWGak+KhsPiQucvOvf2ksVtxoyLQ==
</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</md:KeyDescriptor>
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="http://www.blogsaml.com:4505/content/geometrixx-outdoors/en/saml_login" index="1"/>
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://www.blogsaml.com:8443/idp/Authn/UserPassword"/>
</md:SPSSODescriptor>
</md:EntityDescriptor>- Modify <IDP installed folder>/conf/idp-metadata.xml, to make sure all the location attributes which holds various endpoints for communication are pointing to IDP app on tomcat 8443 or whichever SSL port configured in tomcat. Also make sure the entity id of the IDP is a unique URI. This file also holds certificates that will be used in IDP for SSO and SAML message signing with service provider.
Sample idp-metadata.xml
<?xml version="1.0" encoding="UTF-8"?>
<EntityDescriptor xmlns="urn:oasis:names:tc:SAML:2.0:metadata" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:shibmd="urn:mace:shibboleth:metadata:1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" entityID="https://www.blogsaml.com:8443/idp/shibboleth">
<IDPSSODescriptor protocolSupportEnumeration="urn:mace:shibboleth:1.0 urn:oasis:names:tc:SAML:1.1:protocol urn:oasis:names:tc:SAML:2.0:protocol">
<Extensions>
<shibmd:Scope regexp="false">blogsaml.com</shibmd:Scope>
</Extensions>
<KeyDescriptor use="signing">
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>
MIIDLDCCAhSgAwIBAgIVAPg9in5p91LoulRH1cwQ4kAeg81bMA0GCSqGSIb3DQEB
BQUAMBsxGTAXBgNVBAMMEHd3dy5ibG9nc2FtbC5jb20wHhcNMTYxMTA2MTkwNzAz
WhcNMzYxMTA2MTkwNzAzWjAbMRkwFwYDVQQDDBB3d3cuYmxvZ3NhbWwuY29tMIIB
IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAq0AO+3OFiaXVK0oC6iEA2Ad8
hCZmYQvoVyZ9485a2Ii+FNaofMeAhftvmUHlUeMURmbqvqHAXKIk6Kew66jdhcmY
ICDoF+AqgrhlwQMmG6dm1/DliY5nHgsB4ns1nMVQdq2E5ViiXIXYpUdLywiz5Bz4
jA9FNeFPQDFID0Of6+/CyW7JRIF8m0TxD7IbpRcsTZhbPxz+M/gqHQ37uP9cthQ7
v/cq+YPGy81Gud9LewN9iq4JiY7qU6HliMgKjJtKsgYNY7nS+NnFogNlIFV5rMn3
3UVxiZXKTSvUNkvAcsoIM1lipW6cPJKatno52c88MRuPTHFhiZmtHRpclT2ZvQID
AQABo2cwZTAdBgNVHQ4EFgQUVaCVecDgKxZCzUPmSMMyrk+psLMwRAYDVR0RBD0w
O4IQd3d3LmJsb2dzYW1sLmNvbYYnaHR0cHM6Ly93d3cuYmxvZ3NhbWwuY29tL2lk
cC9zaGliYm9sZXRoMA0GCSqGSIb3DQEBBQUAA4IBAQCOLCOG3jFeyxoHMyFAY3V2
Sw2erT8evmgZ7DCdKGbMZf94ZLOc4hRUWLoWmcxJ7Tc06Ap6GZyS8ZBD1GSyxrL4
RZzKVuhV4u5ifofl0Sjzjy7fx0pag/AW05V5IhosgHqtvYhIQFcNjY/6OhznzMt7
JVlaSfTAo+xVlQob4H9ba7g7GqW684uMbplHrV9CGfpc4pcGC0L151mKk7iF4jvW
4gQsbh5FJU2VpkYnk9WxYCUaNcaawP9RhLTaKfmedMqrpcNPCjHILlV1sEx6Zasl
vc+SR0fIQGunF44u+1zVLCc5BiDmJwLb9kpcI4jDPgs1NBBI9ON5sTEJfrLcjJEc
</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</KeyDescriptor>
<ArtifactResolutionService Binding="urn:oasis:names:tc:SAML:1.0:bindings:SOAP-binding" Location="https://www.blogsaml.com:8443/idp/profile/SAML1/SOAP/ArtifactResolution" index="1"/>
<ArtifactResolutionService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="https://www.blogsaml.com:8443/idp/profile/SAML2/SOAP/ArtifactResolution" index="2"/>
<SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://www.blogsaml.com:8443/idp/profile/SAML2/Redirect/SLO" />
<SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://www.blogsaml.com:8443/idp/profile/SAML2/POST/SLO" />
<SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="https://www.blogsaml.com:8443/idp/profile/SAML2/SOAP/SLO" />
<NameIDFormat>urn:mace:shibboleth:1.0:nameIdentifier</NameIDFormat>
<NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</NameIDFormat>
<SingleSignOnService Binding="urn:mace:shibboleth:1.0:profiles:AuthnRequest" Location="https://www.blogsaml.com:8443/idp/profile/Shibboleth/SSO"/>
<SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://www.blogsaml.com:8443/idp/profile/SAML2/POST/SSO"/>
<SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign" Location="https://www.blogsaml.com:8443/idp/profile/SAML2/POST-SimpleSign/SSO"/>
<SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://www.blogsaml.com:8443/idp/profile/SAML2/Redirect/SSO"/>
</IDPSSODescriptor>
<AttributeAuthorityDescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:1.1:protocol urn:oasis:names:tc:SAML:2.0:protocol">
<Extensions>
<shibmd:Scope regexp="false">blogsaml.com</shibmd:Scope>
</Extensions>
<KeyDescriptor use="signing">
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>
MIIDLDCCAhSgAwIBAgIVAPg9in5p91LoulRH1cwQ4kAeg81bMA0GCSqGSIb3DQEB
BQUAMBsxGTAXBgNVBAMMEHd3dy5ibG9nc2FtbC5jb20wHhcNMTYxMTA2MTkwNzAz
WhcNMzYxMTA2MTkwNzAzWjAbMRkwFwYDVQQDDBB3d3cuYmxvZ3NhbWwuY29tMIIB
IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAq0AO+3OFiaXVK0oC6iEA2Ad8
hCZmYQvoVyZ9485a2Ii+FNaofMeAhftvmUHlUeMURmbqvqHAXKIk6Kew66jdhcmY
ICDoF+AqgrhlwQMmG6dm1/DliY5nHgsB4ns1nMVQdq2E5ViiXIXYpUdLywiz5Bz4
jA9FNeFPQDFID0Of6+/CyW7JRIF8m0TxD7IbpRcsTZhbPxz+M/gqHQ37uP9cthQ7
v/cq+YPGy81Gud9LewN9iq4JiY7qU6HliMgKjJtKsgYNY7nS+NnFogNlIFV5rMn3
3UVxiZXKTSvUNkvAcsoIM1lipW6cPJKatno52c88MRuPTHFhiZmtHRpclT2ZvQID
AQABo2cwZTAdBgNVHQ4EFgQUVaCVecDgKxZCzUPmSMMyrk+psLMwRAYDVR0RBD0w
O4IQd3d3LmJsb2dzYW1sLmNvbYYnaHR0cHM6Ly93d3cuYmxvZ3NhbWwuY29tL2lk
cC9zaGliYm9sZXRoMA0GCSqGSIb3DQEBBQUAA4IBAQCOLCOG3jFeyxoHMyFAY3V2
Sw2erT8evmgZ7DCdKGbMZf94ZLOc4hRUWLoWmcxJ7Tc06Ap6GZyS8ZBD1GSyxrL4
RZzKVuhV4u5ifofl0Sjzjy7fx0pag/AW05V5IhosgHqtvYhIQFcNjY/6OhznzMt7
JVlaSfTAo+xVlQob4H9ba7g7GqW684uMbplHrV9CGfpc4pcGC0L151mKk7iF4jvW
4gQsbh5FJU2VpkYnk9WxYCUaNcaawP9RhLTaKfmedMqrpcNPCjHILlV1sEx6Zasl
vc+SR0fIQGunF44u+1zVLCc5BiDmJwLb9kpcI4jDPgs1NBBI9ON5sTEJfrLcjJEc
</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</KeyDescriptor>
<AttributeService Binding="urn:oasis:names:tc:SAML:1.0:bindings:SOAP-binding" Location="https://www.blogsaml.com:8443/idp/profile/SAML1/SOAP/AttributeQuery"/>
<AttributeService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="https://www.blogsaml.com:8443/idp/profile/SAML2/SOAP/AttributeQuery"/>
<NameIDFormat>urn:mace:shibboleth:1.0:nameIdentifier</NameIDFormat>
<NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</NameIDFormat>
</AttributeAuthorityDescriptor>
</EntityDescriptor>
- Modify <IDP installed folder>/conf/relying-party.xml. Update encryptionassertion to never for SAML2SSO profile,Make additional entry for relying party as below. Point metadata provider to path where adobecq.xml is present
<?xml version="1.0" encoding="UTF-8"?>
<!--
This file is an EXAMPLE configuration file.
This file specifies relying party dependent configurations for the IdP, for example, whether SAML assertions to a
particular relying party should be signed. It also includes metadata provider and credential definitions used
when answering requests to a relying party.
-->
<rp:RelyingPartyGroup xmlns:rp="urn:mace:shibboleth:2.0:relying-party" xmlns:saml="urn:mace:shibboleth:2.0:relying-party:saml"
xmlns:metadata="urn:mace:shibboleth:2.0:metadata" xmlns:resource="urn:mace:shibboleth:2.0:resource"
xmlns:security="urn:mace:shibboleth:2.0:security" xmlns:samlsec="urn:mace:shibboleth:2.0:security:saml"
xmlns:samlmd="urn:oasis:names:tc:SAML:2.0:metadata" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:mace:shibboleth:2.0:relying-party classpath:/schema/shibboleth-2.0-relying-party.xsd
urn:mace:shibboleth:2.0:relying-party:saml classpath:/schema/shibboleth-2.0-relying-party-saml.xsd
urn:mace:shibboleth:2.0:metadata classpath:/schema/shibboleth-2.0-metadata.xsd
urn:mace:shibboleth:2.0:resource classpath:/schema/shibboleth-2.0-resource.xsd
urn:mace:shibboleth:2.0:security classpath:/schema/shibboleth-2.0-security.xsd
urn:mace:shibboleth:2.0:security:saml classpath:/schema/shibboleth-2.0-security-policy-saml.xsd
urn:oasis:names:tc:SAML:2.0:metadata classpath:/schema/saml-schema-metadata-2.0.xsd">
<!-- ========================================== -->
<!-- Relying Party Configurations -->
<!-- ========================================== -->
<rp:AnonymousRelyingParty provider="https://www.blogsaml.com:8443/idp/shibboleth" defaultSigningCredentialRef="IdPCredential"/>
<rp:DefaultRelyingParty provider="https://www.blogsaml.com:8443/idp/shibboleth" defaultSigningCredentialRef="IdPCredential">
<!--
Each attribute in these profiles configuration is set to its default value,
that is, the values that would be in effect if those attributes were not present.
We list them here so that people are aware of them (since they seem reluctant to
read the documentation).
-->
<rp:ProfileConfiguration xsi:type="saml:ShibbolethSSOProfile" includeAttributeStatement="false"
assertionLifetime="PT5M" signResponses="conditional" signAssertions="never"
includeConditionsNotBefore="true"/>
<rp:ProfileConfiguration xsi:type="saml:SAML1AttributeQueryProfile" assertionLifetime="PT5M"
signResponses="conditional" signAssertions="never"
includeConditionsNotBefore="true"/>
<rp:ProfileConfiguration xsi:type="saml:SAML1ArtifactResolutionProfile" signResponses="conditional"
signAssertions="never"/>
<rp:ProfileConfiguration xsi:type="saml:SAML2SSOProfile" includeAttributeStatement="true"
assertionLifetime="PT5M" assertionProxyCount="0"
signResponses="never" signAssertions="always"
encryptAssertions="never" encryptNameIds="never"
includeConditionsNotBefore="true"/>
<rp:ProfileConfiguration xsi:type="saml:SAML2ECPProfile" includeAttributeStatement="true"
assertionLifetime="PT5M" assertionProxyCount="0"
signResponses="never" signAssertions="always"
encryptAssertions="conditional" encryptNameIds="never"
includeConditionsNotBefore="true"/>
<rp:ProfileConfiguration xsi:type="saml:SAML2AttributeQueryProfile"
assertionLifetime="PT5M" assertionProxyCount="0"
signResponses="conditional" signAssertions="never"
encryptAssertions="conditional" encryptNameIds="never"
includeConditionsNotBefore="true"/>
<rp:ProfileConfiguration xsi:type="saml:SAML2ArtifactResolutionProfile"
signResponses="never" signAssertions="always"
encryptAssertions="conditional" encryptNameIds="never"/>
<rp:ProfileConfiguration xsi:type="saml:SAML2LogoutRequestProfile"
signResponses="conditional"/>
</rp:DefaultRelyingParty>
<rp:RelyingParty id="www.blogsaml.com"
provider="https://www.blogsaml.com:88443/idp/shibboleth"
defaultSigningCredentialRef="IdPCredential"
defaultAuthenticationMethod ="urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport">
<rp:ProfileConfiguration xsi:type="saml:SAML2SSOProfile" includeAttributeStatement="true"
assertionLifetime="PT5M" assertionProxyCount="0"
signResponses="never" signAssertions="always"
encryptAssertions="never" encryptNameIds="never"
includeConditionsNotBefore="true"/>
<rp:ProfileConfiguration xsi:type="saml:SAML2ArtifactResolutionProfile"
signResponses="never" signAssertions="always"
encryptAssertions="never" encryptNameIds="never"/>
<rp:ProfileConfiguration xsi:type="saml:SAML2LogoutRequestProfile" signResponses="conditional"/>
</rp:RelyingParty>
<!-- ========================================== -->
<!-- Metadata Configuration -->
<!-- ========================================== -->
<!-- MetadataProvider the combining other MetadataProviders -->
<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="/Users/abc/shibboleth-installation/metadata/idp-metadata.xml"
maxRefreshDelay="P1D" />
<metadata:MetadataProvider xsi:type="metadata:FilesystemMetadataProvider" xmlns="urn:mace:shibboleth:2.0:metadata"
id="AdobeCQ"
metadataFile="/Users/abc/shibboleth-installation/metadata/adobecq.xml"/>
<!-- Example metadata provider. -->
<!-- Reads metadata from a URL and store a backup copy on the file system. -->
<!-- Validates the signature of the metadata and filters out all by SP entities in order to save memory -->
<!-- To use: fill in 'metadataURL' and 'backingFile' properties on MetadataResource element -->
<!--
<metadata:MetadataProvider id="URLMD" xsi:type="metadata:FileBackedHTTPMetadataProvider"
metadataURL="http://example.org/metadata.xml"
backingFile="C:\opt\shibboleth-idp/metadata/some-metadata.xml">
<metadata:MetadataFilter xsi:type="metadata:ChainingFilter">
<metadata:MetadataFilter xsi:type="metadata:RequiredValidUntil"
maxValidityInterval="P7D" />
<metadata:MetadataFilter xsi:type="metadata:SignatureValidation"
trustEngineRef="shibboleth.MetadataTrustEngine"
requireSignedMetadata="true" />
<metadata:MetadataFilter xsi:type="metadata:EntityRoleWhiteList">
<metadata:RetainedRole>samlmd:SPSSODescriptor</metadata:RetainedRole>
</metadata:MetadataFilter>
</metadata:MetadataFilter>
</metadata:MetadataProvider>
-->
</metadata:MetadataProvider>
<!-- ========================================== -->
<!-- Security Configurations -->
<!-- ========================================== -->
<security:Credential id="IdPCredential" xsi:type="security:X509Filesystem">
<security:PrivateKey>/Users/abc/shibboleth-installation/credentials/idp.key</security:PrivateKey>
<security:Certificate>/Users/abc/shibboleth-installation/credentials/idp.crt</security:Certificate>
</security:Credential>
<!-- Trust engine used to evaluate the signature on loaded metadata. -->
<!--
<security:TrustEngine id="shibboleth.MetadataTrustEngine" xsi:type="security:StaticExplicitKeySignature">
<security:Credential id="MyFederation1Credentials" xsi:type="security:X509Filesystem">
<security:Certificate>C:\opt\shibboleth-idp/credentials/federation1.crt</security:Certificate>
</security:Credential>
</security:TrustEngine>
-->
<!-- DO NOT EDIT BELOW THIS POINT -->
<!--
The following trust engines and rules control every aspect of security related to incoming messages.
Trust engines evaluate various tokens (like digital signatures) for trust worthiness while the
security policies establish a set of checks that an incoming message must pass in order to be considered
secure. Naturally some of these checks require the validation of the tokens evaluated by the trust
engines and so you'll see some rules that reference the declared trust engines.
-->
<security:TrustEngine id="shibboleth.SignatureTrustEngine" xsi:type="security:SignatureChaining">
<security:TrustEngine id="shibboleth.SignatureMetadataExplicitKeyTrustEngine" xsi:type="security:MetadataExplicitKeySignature" metadataProviderRef="ShibbolethMetadata"/>
<security:TrustEngine id="shibboleth.SignatureMetadataPKIXTrustEngine" xsi:type="security:MetadataPKIXSignature" metadataProviderRef="ShibbolethMetadata"/>
</security:TrustEngine>
<security:TrustEngine id="shibboleth.CredentialTrustEngine" xsi:type="security:Chaining">
<security:TrustEngine id="shibboleth.CredentialMetadataExplictKeyTrustEngine" xsi:type="security:MetadataExplicitKey" metadataProviderRef="ShibbolethMetadata"/>
<security:TrustEngine id="shibboleth.CredentialMetadataPKIXTrustEngine" xsi:type="security:MetadataPKIXX509Credential" metadataProviderRef="ShibbolethMetadata"/>
</security:TrustEngine>
<security:SecurityPolicy id="shibboleth.ShibbolethSSOSecurityPolicy" xsi:type="security:SecurityPolicyType">
<security:Rule xsi:type="samlsec:Replay" required="false"/>
<security:Rule xsi:type="samlsec:IssueInstant" required="false"/>
<security:Rule xsi:type="samlsec:MandatoryIssuer"/>
</security:SecurityPolicy>
<security:SecurityPolicy id="shibboleth.SAML1AttributeQuerySecurityPolicy" xsi:type="security:SecurityPolicyType">
<security:Rule xsi:type="samlsec:Replay"/>
<security:Rule xsi:type="samlsec:IssueInstant"/>
<security:Rule xsi:type="samlsec:ProtocolWithXMLSignature" trustEngineRef="shibboleth.SignatureTrustEngine"/>
<security:Rule xsi:type="security:ClientCertAuth" trustEngineRef="shibboleth.CredentialTrustEngine"/>
<security:Rule xsi:type="samlsec:MandatoryIssuer"/>
<security:Rule xsi:type="security:MandatoryMessageAuthentication"/>
</security:SecurityPolicy>
<security:SecurityPolicy id="shibboleth.SAML1ArtifactResolutionSecurityPolicy" xsi:type="security:SecurityPolicyType">
<security:Rule xsi:type="samlsec:Replay"/>
<security:Rule xsi:type="samlsec:IssueInstant"/>
<security:Rule xsi:type="samlsec:ProtocolWithXMLSignature" trustEngineRef="shibboleth.SignatureTrustEngine"/>
<security:Rule xsi:type="security:ClientCertAuth" trustEngineRef="shibboleth.CredentialTrustEngine"/>
<security:Rule xsi:type="samlsec:MandatoryIssuer"/>
<security:Rule xsi:type="security:MandatoryMessageAuthentication"/>
</security:SecurityPolicy>
<security:SecurityPolicy id="shibboleth.SAML2SSOSecurityPolicy" xsi:type="security:SecurityPolicyType">
<security:Rule xsi:type="samlsec:Replay"/>
<security:Rule xsi:type="samlsec:IssueInstant"/>
<security:Rule xsi:type="samlsec:SAML2AuthnRequestsSigned"/>
<security:Rule xsi:type="samlsec:ProtocolWithXMLSignature" trustEngineRef="shibboleth.SignatureTrustEngine"/>
<security:Rule xsi:type="samlsec:SAML2HTTPRedirectSimpleSign" trustEngineRef="shibboleth.SignatureTrustEngine"/>
<security:Rule xsi:type="samlsec:SAML2HTTPPostSimpleSign" trustEngineRef="shibboleth.SignatureTrustEngine"/>
<security:Rule xsi:type="samlsec:MandatoryIssuer"/>
</security:SecurityPolicy>
<security:SecurityPolicy id="shibboleth.SAML2AttributeQuerySecurityPolicy" xsi:type="security:SecurityPolicyType">
<security:Rule xsi:type="samlsec:Replay"/>
<security:Rule xsi:type="samlsec:IssueInstant"/>
<security:Rule xsi:type="samlsec:ProtocolWithXMLSignature" trustEngineRef="shibboleth.SignatureTrustEngine"/>
<security:Rule xsi:type="samlsec:SAML2HTTPRedirectSimpleSign" trustEngineRef="shibboleth.SignatureTrustEngine"/>
<security:Rule xsi:type="samlsec:SAML2HTTPPostSimpleSign" trustEngineRef="shibboleth.SignatureTrustEngine"/>
<security:Rule xsi:type="security:ClientCertAuth" trustEngineRef="shibboleth.CredentialTrustEngine"/>
<security:Rule xsi:type="samlsec:MandatoryIssuer"/>
<security:Rule xsi:type="security:MandatoryMessageAuthentication"/>
</security:SecurityPolicy>
<security:SecurityPolicy id="shibboleth.SAML2ArtifactResolutionSecurityPolicy" xsi:type="security:SecurityPolicyType">
<security:Rule xsi:type="samlsec:Replay"/>
<security:Rule xsi:type="samlsec:IssueInstant"/>
<security:Rule xsi:type="samlsec:ProtocolWithXMLSignature" trustEngineRef="shibboleth.SignatureTrustEngine"/>
<security:Rule xsi:type="samlsec:SAML2HTTPRedirectSimpleSign" trustEngineRef="shibboleth.SignatureTrustEngine"/>
<security:Rule xsi:type="samlsec:SAML2HTTPPostSimpleSign" trustEngineRef="shibboleth.SignatureTrustEngine"/>
<security:Rule xsi:type="security:ClientCertAuth" trustEngineRef="shibboleth.CredentialTrustEngine"/>
<security:Rule xsi:type="samlsec:MandatoryIssuer"/>
<security:Rule xsi:type="security:MandatoryMessageAuthentication"/>
</security:SecurityPolicy>
<security:SecurityPolicy id="shibboleth.SAML2SLOSecurityPolicy" xsi:type="security:SecurityPolicyType">
<security:Rule xsi:type="samlsec:Replay"/>
<security:Rule xsi:type="samlsec:IssueInstant"/>
<security:Rule xsi:type="samlsec:ProtocolWithXMLSignature" trustEngineRef="shibboleth.SignatureTrustEngine"/>
<security:Rule xsi:type="samlsec:SAML2HTTPRedirectSimpleSign" trustEngineRef="shibboleth.SignatureTrustEngine"/>
<security:Rule xsi:type="samlsec:SAML2HTTPPostSimpleSign" trustEngineRef="shibboleth.SignatureTrustEngine"/>
<security:Rule xsi:type="security:ClientCertAuth" trustEngineRef="shibboleth.CredentialTrustEngine"/>
<security:Rule xsi:type="samlsec:MandatoryIssuer"/>
<security:Rule xsi:type="security:MandatoryMessageAuthentication"/>
</security:SecurityPolicy>
</rp:RelyingPartyGroup>
5. Configuring AEM
- Install AEM 6.2. You can request for trial version by completing the form https://solutionpartners.adobe.com/home/enablement/access/mc-products.html
- Start the instance and navigate to crx/de, under /etc/key in the repository, create a node called “saml”. Inside this node, add a new binary property called “idp_cert” for the public certificate of the IdP and upload the file from <IDP installed folder>/credentials/idp.crt. This will be used to validate SAML request and response from IDP.
- Configure Authentication Handler. Here we need to set values for IDP Post URL with the right port and SP ID. Sample Configuration is as below. use the right https port
- Configure ReferrerFilter.
- Make a request to AEM at http://<host> : <port>/ which redirects to IDP login page.
- Login with user created in active directory with appropriate credentials this takes you to the AEM home page.
Conclusion
Through this article I have explained how we can achieve SSO with SAML authentication(secure authentication method). Since AEM supports SAML 2.0 Authentication and comes with SAML authentication handler, it makes integration with IDP simpler and quicker.
References
No Comments