Enabling SSO with CQ5 – Part II

Technology

11 / Mar / 2014 by Geetika Chhabra 6 comments

In first part of our tri-part blog series , we discussed about the installation and configuration of Shibboleth IdP. We’ll be focusing on the following two use cases :

Use-Case I : Protecting CQ5 author instance when CQ5 acts as a service provider (SP).

Use-Case II: Protecting any published resource/website.

This blogpost will target to provide the solution for the first use case and provide a way to protect CQ5 author instance.

Basic Workflow:

When user accesses a protected resource, the SP determines if the user has an active session. If there is no valid session, SP will prepare an authentication request and send that SAML authentication request to IdP. Shibboleth IdP will check for valid session on its end, if no session exists, login screen will be presented to the user to enter the login credentials. IdP will in turn request LDAP for user credentials, fetches the necessary information, generates a SAML response and send it to SP. User is now trying again to access the protected resource, but this time the user has a session and SP knows who they are. SP will service the user’s request and send back the requested data.

AEM provides support for the SAML 2.0 Authentication Request and can act as a SAML service provider.

Necessary Steps :

Installing LDAP Server.
Installing Shibboleth IdP.
Installing Apache tomcat on Ubuntu.
Configuring Shibboleth IdP.
Creating the SP’s metadata file (AEM in this case ) and providing it to IdP.
AEM configuration.
Accessing AEM author instance.

Steps 1-4 have already been covered in Part I. Subsequent steps are explained below :

Creating the SP’s metadata file (AEM in this case ) and providing it to IdP.

As AEM is acting as an SP, it needs to provide it’s metadata file to IdP. Create and open a file say <SAML_IDP_HOME>metadata/adobecq.xml and paste the below :

[xml]<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" entityID="https://sp.intelligrape.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>
//copy the public key from <SAML_IDP_HOME>/credentials/idp.crt and paste here
</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</md:KeyDescriptor>

<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="http://localhost:4502/saml_login" index="1"/>
</md:SPSSODescriptor>
</md:EntityDescriptor> [/xml]

In relyingParty.xml, we need to specify the details of IdP’s metadata and any other service provider’s metadata file that relies on our IdP. IdP’s metadata file is already provided in Part I. While specifying the relying party and metadata of AEM (SP), value of Provider attribute in <rp:RelyingParty> tag should be the same as that of EntityId specified in above metadata file. Also, change encryptAssertions attribute to “never”.

[xml]<rp:RelyingParty id="sp.intelligrape.com" provider="https://sp.intelligrape.com" 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="<strong>never</strong>" encryptNameIds="never"/>
<rp:ProfileConfiguration xsi:type="saml:SAML2LogoutRequestProfile"
signResponses="conditional"/>
</rp:RelyingParty>[/xml]

Provide the AEM’s metadata file created in above step to IdP:

[xml]<metadata:MetadataProvider id="CQMETADATA" xsi:type="metadata:FilesystemMetadataProvider"
metadataFile="/opt/shibboleth-idp/metadata/adobecq.xml"
maxRefreshDelay="P1D" />[/xml]

AEM configuration.

For better understanding of SAML 2.0 Authentication Handler, please go through the official documentation . As mentioned in documentation, we need to provide the public and private keys to AEM. After creating a node named saml under /etc/key

Create a binary property idp_cert inside this node and upload the idp.crt file from <SAML_IDP_HOME>/credentials/idp.crt path.
Create a binary property private inside this node .Upload the below mentioned newly converted key here.The private key must be in PKCS8 format. To convert a PEM encoded private key to PKCS8 with openssl :

[shell]openssl pkcs8 -topk8 -inform PEM -outform DER -in idp.key -nocrypt > pkcs8.key[/shell]

where idp.key is the key that needs to be converted and pkcs8.key is the resulted key after conversion.

Update the ReferrerFilter,add the <IDP Hostname> in allow hosts property.

In Adobe Granite SAML 2.0 Authentication handler :

Set the IdP URL to the path where the SAML authentication request should be sent to or simply paste the below :
Set the SP provider id to the ID specified in above metadata file (adobecq.xml) i.e.
Uncheck the Use Encryption property in Adobe Granite SAML 2.0 Authentication Handler.
User Id attribute’s value should be the same as the ID of the <SAML Attribute > that contains the user id to authenticate the user.
For GroupMembership property , provide the id of the <SAML Attribute > here which will contain the list of groups to which the user will be added to after creation. You can add an attribute called “OU” in user profiles maintained in LDAP. Value of this attribute should be the valid group name present in CRX. Make sure you release the attribute and do the necessary configuration needed in <SAML_IDP_HOME>/conf/attribute-resolver.xml and <SAML_IDP_HOME>/conf/attribute-filter.xmlfiles. Refer Part I for more details. Please note that the value of the GroupMembership property should be the same as you provide the ID of the attribute “OU” in attribute-resolver.xml file.

Refer the below image :

Accessing AEM author instance.

Making a request to AEM at http://<host>:<port>/ should redirect to IdP login page . Try to login with valid user profiles maintained in LDAP. You should be able to login if credentials are valid and all the above configuration is correct.

Troubleshooting Steps:

After getting the IdP login screen, you log in using an LDAP user credential and are presented with a 404 error code and an error stack trace on welcome page.

This means that the imported user does not have appropriate READ permissions. You could give READ permission to this user, although the appropriate way would be to give READ permission to the group (say “iggroup”) to which imported LDAP users are assigned as members.It can be achieved by creating a group “iggroup” as member of the “contributor” group so that “iggroup” inherits the default permissions from the “contributor” group. In SAML authentication handler service , we specify the group membership attribute which will contain the list of groups the newly created user will be added to. To achieve this, add an attribute say ou in LDAP user profile , and specify the same attribute name in IdP attribute-filter.xml file. The id specified in attribute-filter.xml will be used as the value for groupMembership attribute in SAML handler.

If IdP login page doesn’t appear , cross check the configuration again.

References :

http://helpx.adobe.com/experience-manager/kb/saml-demo.html

http://dev.day.com/content/docs/en/cq/current/core/administering/saml-2-0-authenticationhandler.html

comments (6)

RaviDecember 17, 2015 at 6:09 am

Hi.
I am quite late on this one.
I have followed all the steps but when I login in , I always get “Login has failed. Double-check your username and password.”
In SAML Tracer I do not see the reqquest going to localhostLxxxx/saml_login. Wondering why.
Have spent two full days trying to figure out 🙁

Help would be appreciated

Reply ↓
NishaDecember 8, 2015 at 4:11 pm

Hi Geetika , Thanks for sharing this knowledge base with us . Refering to your point “Creating the SP’s metadata file (AEM in this case ) and providing it to IdP.” -> I am not sure if this needs to be manually created by us or it gets automatically generated in AEM as I am new to SAMl confiurations.

Using below file and replacing IDP url / entity ID respectively will help?

urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress

Reply ↓
Tridib BolarNovember 3, 2015 at 11:56 am

Hi Geetika, I am trying to integrate AEM 6.1 with OKTA SSO. I provide following configuration in OKTA end. 1) SP URL, 2) NameIDFormat – “urn:oasis:names:tc:SAML:2.0:nameid-format:transient” rest of the configurations are default. In AEM end I provide following information, 1) IDP URL (OKTA URL), 2) Service Provider Entity ID, 3) Create trust store by supplying the password & then upload the IdP certificate 4) Create KeyStore by supplying the password 5) Rest of the configuration I did as per the “http://www.aemstuff.com/blogs/july/saml.html” URL. But when I am trying to execute the AEM I am getting “com.adobe.granite.auth.saml.SamlAuthenticationHandler Private key of SP not provided: Cannot sign Authn request” warning and the screen is blinking continuously. I may have to provide some public or private key, but I am not sure who will provide that key and where I have to import that. Could you please help me on this issue?

Thanks
Tridib

Reply ↓
SamMay 16, 2014 at 1:06 pm

Thanks Geetika for your help! It worked when I added 1. buisnessCategory value as “administrators” to LDAP user profile 2. Set attributeid as “group” in attribute-filter.xml and felix console as “group”. It seems any other word such as “iggroup” in both attribute-filter.xml and felix console does not work. Any idea?

Reply ↓
GeetikaMay 15, 2014 at 9:12 pm

Hi Sam, In felix console , the value of GroupMembership should be the same as that of the “attributeId” which you’ll specify in “attribute-filter.xml”.

In your case, you have specified the attributeId as “buisnessCategory” (which contains the value “administrators” ) so you need to specify the groupMembership attribute as “buisnessCategory” rather than “administrators”. Currently, it is trying to look for the attribute named “administrators” which unfortunately is not being released from LDAP.

Reply ↓
SamMay 15, 2014 at 8:23 pm

Hi Geetika, I’m facing issue with 404…I have mentioned “businessCategory” attributeID in attribute-filter.xml and the same attribute(“businessCategory”) I have mentioned in Apache DS LDAP for user and the value I have set is “administrators”. Now in Felix console I have also set the value of Group Membership as “administrators”, but CQ is not able to assign any user to “administrators” group, Kindly let me know what I’m missing here.

Reply ↓

Blogs

Enabling SSO with CQ5 – Part II

comments (6)

Leave a Reply Cancel reply

Blogs

Tag -

comments (6)

Leave a Reply Cancel reply

Tips for writing a blog

Learn how to write a caption