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).
- 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.
- 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 :
<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> <SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="http://idp.intelligrape.com/Shibboleth.sso/SLO/SOAP" xmlns="urn:oasis:names:tc:SAML:2.0:metadata"/> <SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="http://idp.intelligrape.com/Shibboleth.sso/SLO/Redirect" xmlns="urn:oasis:names:tc:SAML:2.0:metadata"/> <SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="http://idp.intelligrape.com/Shibboleth.sso/SLO/POST" xmlns="urn:oasis:names:tc:SAML:2.0:metadata"/> <SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" Location="http://idp.intelligrape.com/Shibboleth.sso/SLO/Artifact" xmlns="urn:oasis:names:tc:SAML:2.0:metadata"/> <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>
-
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, changeencryptAssertions
attribute to “never”.<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>
-
Provide the AEM’s metadata file created in above step to IdP:
<metadata:MetadataProvider id="CQMETADATA" xsi:type="metadata:FilesystemMetadataProvider" metadataFile="/opt/shibboleth-idp/metadata/adobecq.xml" maxRefreshDelay="P1D" />
- 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 theidp.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 :
openssl pkcs8 -topk8 -inform PEM -outform DER -in idp.key -nocrypt &gt; pkcs8.key
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 : https://idp.intelligrape.com:8443/idp/profile/SAML2/POST/SSO
-
Set the SP provider id to the ID specified in above metadata file (adobecq.xml) i.e. https://sp.intelligrape.com
-
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.xml
files. 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” inattribute-resolver.xml
file.
- 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://www.citytechinc.com/us/en/blog/2013/02/configuring-saml-in-aem-5-6.html
http://dev.day.com/content/docs/en/cq/current/core/administering/saml-2-0-authenticationhandler.html
P.S. This post was originally published on my company’s website.
Hope it helps !! 🙂