Resource at '/saml_login' is not modifiable. | Community
Skip to main content
Level 2
March 17, 2022
Solved

Resource at '/saml_login' is not modifiable.

  • March 17, 2022
  • 3 replies
  • 2197 views

We're using OOTB SAML auth handler for authentication and we have no issue with login and same being used since long time. However, For some reason we see below error in our logs occasionally and the same reported by the AMS team. We're not able to reproduce this issue at all. Did anyone come across such issue and any suggestions on how we can reproduce or avoid this error?

 

POST /saml_login HTTP/1.1] org.apache.sling.servlets.post.impl.operations.ModifyOperation Exception during response processing.
org.apache.sling.api.resource.PersistenceException: Resource at '/saml_login' is not modifiable.
at org.apache.sling.servlets.post.impl.helper.SlingPropertyValueHandler.setProperty(SlingPropertyValueHandler.java:114) [org.apache.sling.servlets.post:2.3.26]

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

That's a classic one. Let me walk you through my thinking:

 

  1. /saml_login as a path is not a path which is stored in the JCR repository (there we only have /libs, /apps, /content /var, /etc/, /oak:index, /jcr:system at the toplevel).
  2. It seems that here the SlingPostServlet fails to create this path in the repository (most likely missing write permissions).
  3. But is that really, what we can and should expect? "saml login" sounds like that someone tries to login via SAML, right?
  4. In that case we can imagine, that instead of creating a resource at /saml_login, rather a servlet bound to /saml_login should be invoked.
  5. But why is the SlingPostServlet invoked, if we would expect that another servlet is called?
  6. For background: The SlingPostServlet is registered as default, if no other servlet takes precedence, and it tries to create/modify resources in the repository.
  7. So in this case we expect that a servlet is invoked, but it is not. Which just leaves us with a single explanation:
  8. The servlet which we expect to be bound at /saml_login is not active.

So you should start the troubleshooting like this:

 

* do these messages just appear in single instances? Or rather in batches?

* can you correlate it with start and stop of other services?

 

 

 

 

3 replies

Himanshu_Jain
Community Advisor
Community Advisor
March 17, 2022

Check ACLs whether you have write permission or not.

Himanshu Jain
joerghoh
Adobe Employee
joerghohAdobe EmployeeAccepted solution
Adobe Employee
March 17, 2022

That's a classic one. Let me walk you through my thinking:

 

  1. /saml_login as a path is not a path which is stored in the JCR repository (there we only have /libs, /apps, /content /var, /etc/, /oak:index, /jcr:system at the toplevel).
  2. It seems that here the SlingPostServlet fails to create this path in the repository (most likely missing write permissions).
  3. But is that really, what we can and should expect? "saml login" sounds like that someone tries to login via SAML, right?
  4. In that case we can imagine, that instead of creating a resource at /saml_login, rather a servlet bound to /saml_login should be invoked.
  5. But why is the SlingPostServlet invoked, if we would expect that another servlet is called?
  6. For background: The SlingPostServlet is registered as default, if no other servlet takes precedence, and it tries to create/modify resources in the repository.
  7. So in this case we expect that a servlet is invoked, but it is not. Which just leaves us with a single explanation:
  8. The servlet which we expect to be bound at /saml_login is not active.

So you should start the troubleshooting like this:

 

* do these messages just appear in single instances? Or rather in batches?

* can you correlate it with start and stop of other services?

 

 

 

 

Level 2
June 15, 2024

Hi @joerghoh @himanshu_jain  @prajwalreddi 

I have also face this exact issue recently and in my case, it was the certificate alias which was mismatching i.e. the alias from Truststore console was different than the one configured in the SAML OSGI configuration.

 

Thanks for posting the question and answers.