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.

 

Screen Shot 2018-12-19 at 4.54.36 pm.png

Setting up the Environment 

Softwares used for the setup

The binaries used are mentioned below.

Software

Version

Downloaded from

Shibboleth IDP

2.4.4

http://shibboleth.net/downloads/identity-provider/latest/

Tomcat (App server for IDP)

apache-tomcat-8.5.35

http://tomcat.apache.org/download-60.cgi

Apache Directory Service Specific to OS

ApacheDS-2.0

http://directory.apache.org/apacheds/downloads.html

Apache  Directory Studio(Client to connect to ApacheDS)

Apache Directory Studio-2.0

https://directory.apache.org/studio/

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.

  1. 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.
  2. To create a new connection click the  New Connection button. image1-18.png
  3. 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. image3-19.png
    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

  4. 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. image4-22.png
  5. 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

  6. Observe that the Connections view now shows the created connection.
  7.  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.image6-28.gif
  8. Right-click on the ou=users node and select New Entry. The New Entry wizard appears.
  9. In the Entry Creation Method pane, you do not need to change any settings. Click Next.
  10. 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                     image7-31.gif
  11. 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.
  12. 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.                     image9-37.gif
  13. Add a userPassword attribute to the user entry.
  14. 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.
  15. The Password Editor dialog appears. In the Enter New Password field, enter the password, “secret”. Click Ok.
  16. 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 

Screen Shot 2018-12-03 at 1.02.59 pm.png

Structure of  the credentials folder holding  certificate and keys

Screen Shot 2018-12-03 at 1.13.10 pm.png

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 more

4. 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.

Screen Shot 2018-12-03 at 2.29.01 pm.png

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>
image29-96.png
  • 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.”
<?xml version="1.0" encoding="UTF-8"?>

<ph:ProfileHandlerGroup xmlns:ph="urn:mace:shibboleth:2.0:idp:profile-handler" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:mace:shibboleth:2.0:idp:profile-handler classpath:/schema/shibboleth-2.0-idp-profile-handler.xsd">

<!-- Error Handler -->
<ph:ErrorHandler xsi:type="ph:JSPErrorHandler" jspPagePath="/error.jsp"/>

<!-- Profile Handlers -->
<!--
All profile handlers defined below are accessed via the Servlet path "/profile" so if your profile
handler's request path is "/Status" then the full path is "<servletContextName>/profile/Status"
-->
<ph:ProfileHandler xsi:type="ph:Status">
<ph:RequestPath>/Status</ph:RequestPath>
</ph:ProfileHandler>

<ph:ProfileHandler xsi:type="ph:SAMLMetadata" metadataFile="C:\opt\shibboleth-idp/metadata/idp-metadata.xml">
<ph:RequestPath>/Metadata/SAML</ph:RequestPath>
</ph:ProfileHandler>

<ph:ProfileHandler xsi:type="ph:ShibbolethSSO" inboundBinding="urn:mace:shibboleth:1.0:profiles:AuthnRequest"
outboundBindingEnumeration="urn:oasis:names:tc:SAML:1.0:profiles:browser-post
urn:oasis:names:tc:SAML:1.0:profiles:artifact-01">
<ph:RequestPath>/Shibboleth/SSO</ph:RequestPath>
</ph:ProfileHandler>

<ph:ProfileHandler xsi:type="ph:SAML1AttributeQuery" inboundBinding="urn:oasis:names:tc:SAML:1.0:bindings:SOAP-binding"
outboundBindingEnumeration="urn:oasis:names:tc:SAML:1.0:bindings:SOAP-binding">
<ph:RequestPath>/SAML1/SOAP/AttributeQuery</ph:RequestPath>
</ph:ProfileHandler>

<ph:ProfileHandler xsi:type="ph:SAML1ArtifactResolution" inboundBinding="urn:oasis:names:tc:SAML:1.0:bindings:SOAP-binding"
outboundBindingEnumeration="urn:oasis:names:tc:SAML:1.0:bindings:SOAP-binding">
<ph:RequestPath>/SAML1/SOAP/ArtifactResolution</ph:RequestPath>
</ph:ProfileHandler>

<ph:ProfileHandler xsi:type="ph:SAML2SSO" inboundBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
outboundBindingEnumeration="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign
urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST
urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact">
<ph:RequestPath>/SAML2/POST/SSO</ph:RequestPath>
</ph:ProfileHandler>

<ph:ProfileHandler xsi:type="ph:SAML2SSO" inboundBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign"
outboundBindingEnumeration="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign
urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST
urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact">
<ph:RequestPath>/SAML2/POST-SimpleSign/SSO</ph:RequestPath>
</ph:ProfileHandler>

<ph:ProfileHandler xsi:type="ph:SAML2SSO" inboundBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"
outboundBindingEnumeration="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign
urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST
urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact">
<ph:RequestPath>/SAML2/Redirect/SSO</ph:RequestPath>
</ph:ProfileHandler>

<ph:ProfileHandler xsi:type="ph:SAML2SSO" inboundBinding="urn:mace:shibboleth:2.0:profiles:AuthnRequest"
outboundBindingEnumeration="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign
urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST
urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact">
<ph:RequestPath>/SAML2/Unsolicited/SSO</ph:RequestPath>
</ph:ProfileHandler>

<ph:ProfileHandler xsi:type="ph:SAML2ECP" inboundBinding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP"
outboundBindingEnumeration="urn:oasis:names:tc:SAML:2.0:bindings:SOAP">
<ph:RequestPath>/SAML2/SOAP/ECP</ph:RequestPath>
</ph:ProfileHandler>

<ph:ProfileHandler xsi:type="ph:SAML2SLO" inboundBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"
outboundBindingEnumeration="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect
urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign
urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST
urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact">
<ph:RequestPath>/SAML2/Redirect/SLO</ph:RequestPath>
</ph:ProfileHandler>

<ph:ProfileHandler xsi:type="ph:SAML2SLO" inboundBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
outboundBindingEnumeration="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect
urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign
urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST
urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact">
<ph:RequestPath>/SAML2/POST/SLO</ph:RequestPath>
</ph:ProfileHandler>

<ph:ProfileHandler xsi:type="ph:SAML2SLO" inboundBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign"
outboundBindingEnumeration="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect
urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign
urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST
urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact">
<ph:RequestPath>/SAML2/POST-SimpleSign/SLO</ph:RequestPath>
</ph:ProfileHandler>

<ph:ProfileHandler xsi:type="ph:SAML2SLO" inboundBinding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP"
outboundBindingEnumeration="urn:oasis:names:tc:SAML:2.0:bindings:SOAP">
<ph:RequestPath>/SAML2/SOAP/SLO</ph:RequestPath>
</ph:ProfileHandler>

<ph:ProfileHandler xsi:type="ph:SAML2SLO" inboundBinding="urn:mace:shibboleth:2.0:profiles:LocalLogout">
<ph:RequestPath>/Logout</ph:RequestPath>
</ph:ProfileHandler>

<ph:ProfileHandler xsi:type="ph:SAML2AttributeQuery" inboundBinding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP"
outboundBindingEnumeration="urn:oasis:names:tc:SAML:2.0:bindings:SOAP">
<ph:RequestPath>/SAML2/SOAP/AttributeQuery</ph:RequestPath>
</ph:ProfileHandler>

<ph:ProfileHandler xsi:type="ph:SAML2ArtifactResolution" inboundBinding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP"
outboundBindingEnumeration="urn:oasis:names:tc:SAML:2.0:bindings:SOAP">
<ph:RequestPath>/SAML2/SOAP/ArtifactResolution</ph:RequestPath>
</ph:ProfileHandler>

<!-- Login Handlers
<ph:LoginHandler xsi:type="ph:RemoteUser">
<ph:AuthenticationMethod>urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified</ph:AuthenticationMethod>
</ph:LoginHandler>
-->
<!-- Login handler that delegates the act of authentication to an external system. -->
<!-- This login handler and the RemoteUser login handler will be merged in the next major release. -->
<!--
<ph:LoginHandler xsi:type="ph:ExternalAuthn">
<ph:AuthenticationMethod>urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified</ph:AuthenticationMethod>
<ph:QueryParam name="foo" value="bar" />
</ph:LoginHandler>
-->

<!-- Username/password login handler -->
<!-- -->
<ph:LoginHandler xsi:type="ph:UsernamePassword"
jaasConfigurationLocation="/Users/abc/shibboleth-installation/conf/login.config">
<ph:AuthenticationMethod>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</ph:AuthenticationMethod>
</ph:LoginHandler>


<!--
Removal of this login handler will disable SSO support, that is it will require the user to authenticate
on every request.
-->
<ph:LoginHandler xsi:type="ph:PreviousSession">
<ph:AuthenticationMethod>urn:oasis:names:tc:SAML:2.0:ac:classes:PreviousSession</ph:AuthenticationMethod>
</ph:LoginHandler>

</ph:ProfileHandlerGroup>
  • 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>
Screen Shot 2018-12-03 at 3.40.12 pm.png
Screen Shot 2018-12-03 at 3.40.27 pm.png

 

  • 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>

image26-87.png

image27-90.png

    1.  

5.  Configuring  AEM

  1. Install AEM 6.2. You can request for trial version by completing the form  https://solutionpartners.adobe.com/home/enablement/access/mc-products.html
  2. 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.image32-105.png
  3. 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 Adobe Experience Manager Web Console - Configuration.jpg
  4. Configure ReferrerFilter.

Adobe Experience Manager Web Console - Configuration (1).jpg

Note: For AEM 6.3 and above follow below steps for configuring idp certificate

  • Navigate to crx/de and login with admin credentials.
  • Navigate to http://<host>/libs/granite/security/content/useradmin.html.
  • Select admin user for demo purpose
  • Go under Account Settings and press the Create TrustStore link.
  • Enter the password for the TrustStore and click Save. 
  • After creating the trust store, we need to upload IdP certificate from <IDP installed folder>/credentials/idp.crt so that the SAML Request and Response can be validated against that certificate. 

6.   Verify if SSO is working as expected

  • Make a request to AEM at http://<host&gt; : <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.
image35-114.png

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

  1. Demonstration of AEM and SAML integration
  2. Shibboleth Concepts

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s