Level 3

SAML Integration failing on post back to AEM

Forum|Forum|9 years ago
April 7, 2016
2 replies
8022 views

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!

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.

kautuk_sahni

Community Manager

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-manager.topic.html/forum__4hsn-hi_i_am_working.html

//

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

C

courtthreeGDCAuthor

Level 3

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?

K

Kkkrish

Level 4

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

A

abhishekb

Level 3

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.

C

courtthreeGDCAuthor

Level 3

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?

A

abhishekb

Level 3

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.

Error while processing /content/adobedemolab/saml_login.html

Sign up

Login with SSO

Login to the community

Login with SSO

Scanning file for viruses.

This file cannot be downloaded