SAML Integration failing on post back to AEM

[courtthreeGDC]

Hey guys,

I have been working on integrating a client's SSO with AEM 5.6.1. They are using ADFS and SAML.

I have successfully configured the SAML integration handler and the protected node is happily bouncing to the client's ADFS log-in screen when hit with the browser.

The ADFS is then posting back to <myURL>/saml_login (which I understand to be the address of the handler for the post back) but I am seeing the following error:

Error while processing

             

Status	500
Message	javax.jcr.RepositoryException: org.apache.sling.api.resource.PersistenceException: Resource at 'REDACTED FOR SECURITY' is not modifiable.

Now, I've only seen the "not modifiable" error when we are posting to a URL that doesn't accept post. It would appear that the /saml_login handler is not even attempting to intercept the inbound query and CQ is simply giving a standard error that you'd expect if you posted to any resource.

What am I missing? Is there a known "missing step" in Adobe's documentation for SAML integration? Any help greatly appreciated!

[kautuk_sahni]

Hi

Solution:- http://adobeaemclub.com/exception-while-calling-a-servlet-in-aem/

OR

Please have a look at this old forum post,

There a user faced the same problem and also posted the solution for it in comment section.

Link:- http://help-forums.adobe.com/content/adobeforums/en/experience-manager-forum/adobe-experience-manage...

//

Error while processing /content/adobedemolab/saml_login.html

             

Status	500
Message	javax.jcr.RepositoryException: org.apache.sling.api.resource.PersistenceException: Resource at '/content/adobedemolab/saml_login.html' is not modifiable.
Location	/content/adobedemolab/saml_login.html

Sol:- the url on IDP side contained the extension on removing that I was successfully able to consume the response and authenticate the url. 

I hope this would act as some help to you.

Thanks and Regards

Kautuk Sahni

[courtthreeGDC]

Thanks so much for helping.

Unfortunately, I have implemented the changes above to no avail. In fact, I get exactly the same error as before.

In terms of your first solution (about a call to a servlet errorring), given that we are using the built in SAML handler, we shouldn't need to register the servlet path should we?

I have done a a SAML trace and got the following response:

<samlp:Response ID="•••REDACTED•••" Version="2.0" IssueInstant="2016-04-08T14:39:53.363Z" Destination="•••REDACTED•••" Consent="urn:oasis:names:tc:SAML:2.0:consent:unspecified" InResponseTo="•••REDACTED•••" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" > <Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">•••REDACTED•••</Issuer> <Signature xmlns="http://www.w3.org/2000/09/xmldsig#"> <SignedInfo> <CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" /> <SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256" /> <Reference URI="•••REDACTED•••"> <Transforms> <Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" /> <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" /> </Transforms> <DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256" /> <DigestValue>•••REDACTED•••</DigestValue> </Reference> </SignedInfo> <SignatureValue>•••REDACTED•••</SignatureValue> <KeyInfo> <ds:X509Data xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <ds:X509Certificate>•••REDACTED•••</ds:X509Certificate> </ds:X509Data> </KeyInfo> </Signature> <samlp:Status> <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Requester"> <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:InvalidNameIDPolicy" /> </samlp:StatusCode> </samlp:Status> </samlp:Response>

The thing that draws my eye is the "InvalidNameIDPolicy" on the 4th to last line. Does that mean anything and, if so, what to do?

[Kkkrish]

courtthreeGDC wrote...

Thanks so much for helping.

Unfortunately, I have implemented the changes above to no avail. In fact, I get exactly the same error as before.

In terms of your first solution (about a call to a servlet errorring), given that we are using the built in SAML handler, we shouldn't need to register the servlet path should we?

I have done a a SAML trace and got the following response:

<samlp:Response ID="•••REDACTED•••" Version="2.0" IssueInstant="2016-04-08T14:39:53.363Z" Destination="•••REDACTED•••" Consent="urn:oasis:names:tc:SAML:2.0:consent:unspecified" InResponseTo="•••REDACTED•••" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" > <Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">•••REDACTED•••</Issuer> <Signature xmlns="http://www.w3.org/2000/09/xmldsig#"> <SignedInfo> <CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" /> <SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256" /> <Reference URI="•••REDACTED•••"> <Transforms> <Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" /> <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" /> </Transforms> <DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256" /> <DigestValue>•••REDACTED•••</DigestValue> </Reference> </SignedInfo> <SignatureValue>•••REDACTED•••</SignatureValue> <KeyInfo> <ds:X509Data xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <ds:X509Certificate>•••REDACTED•••</ds:X509Certificate> </ds:X509Data> </KeyInfo> </Signature> <samlp:Status> <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Requester"> <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:InvalidNameIDPolicy" /> </samlp:StatusCode> </samlp:Status> </samlp:Response>

The thing that draws my eye is the "InvalidNameIDPolicy" on the 4th to last line. Does that mean anything and, if so, what to do?

Can you please cross verify the IDP NameIDPolicy is matching with your AEM SAML configuration of NameIDPolicy Format.?

[courtthreeGDC]

Thanks KK,

Agreed, this sounds very sensible. Can you elaborate further in terms of exactly what should match with what?

[Kkkrish]

Attached the example for verification

[abhishekb]

What is the post back URL ? If you've configured the SAML handler for intercepting the path /abc/def, the post back URL has to be /abc/def/saml_login. I've made this mistake in the past. Unfortunately this is not documented. I hope you've taken care of this.

[courtthreeGDC]

Thanks @abhishekb, you're right it's not documented. I had found this on a blog somewhere and dealt with it already.

Since my last post, I have found that the SAML bundle was not working as expected at all. If you follow https://helpx.adobe.com/experience-manager/kb/saml-demo.html (as we did) the SAML Authentication Handler does not cut in when you request the protected page.

We have found that you can only get the SAML Authentication Handler to work if you also add the protected path to the "Authentication Requirements" node of the "Apache Sling Authentication Service" bundle.

I'd be very interested for you guy to verify this on your AEMs as it seems like an unbelievable oversight from Adobe?!

1. Implement the SAML configuration as per Adobe's documentation: https://helpx.adobe.com/experience-manager/kb/saml-demo.html

2. Protect a node of the CRX under the "/content/" node.

3. Use a different, non-logged in browser to hit the page and observe that the SAML Authentication Handler takes no action.

4. Add the protected path to the "Authentication Requirements" node of the "Apache Sling Authentication Service" and observe that this is required for the content node to be protected (contrary to Adobe's documentation).

What do you guys think?

[abhishekb]

I did not have to make any change in this setting when I configured SAML. I just checked this config after reading your post. Its set to enable auth for root path /. I don't recall making any change here.

[courtthreeGDC]

Thanks so much again for your continued support.

The thing is that the Apache Sling Authentication Service: Authentication Requirements had no entries at all my client's instance (until I added it there during this process). The site running on there is a public website and has not been protected before. The SAML integration is only relevant for a small part of the site residing a specific node in the CRX. So, having added this node to the SAML Authentication Handler (as per the documentation), it didn't work until I also added it into the Apache Sling Authentication Service: Authentication Requirements property in the OSGI Configuration.

I'd be very interested to know from you guys whether your instance behaves the same and I would be very interested to hear from Adobe why they have not mentioned this?!

[Sham_HC]

courtthreeGDC wrote...

The thing is that the Apache Sling Authentication Service: Authentication Requirements had no entries at all my client's instance (until I added it there during this process). The site running on there is a public website and has not been protected before. The SAML integration is only relevant for a small part of the site residing a specific node in the CRX. So, having added this node to the SAML Authentication Handler (as per the documentation), it didn't work until I also added it into the Apache Sling Authentication Service: Authentication Requirements property in the OSGI Configuration.

I'd be very interested to know from you guys whether your instance behaves the same and I would be very interested to hear from Adobe why they have not mentioned this?!

In general publish instance is read only and accessible to anonymous user. If you want to protect need to configure CUG[1]. For saml on publish instance need either cug enabled [1] or added Authentication Requirements property in the OSGI Configuration

[1]  https://docs.adobe.com/docs/en/aem/6-0/administer/security/cug.html