Currently, we have SSO enabled in our web application and works well. But, when an user is configured in SSO but not in our web application, we are having a redirect loop.
We have noticed that, when this happens, webapp invokes an URL like this:
/login.jsp?errormsg=The+User%3A+SOMEUSER+doesn%27t+exist And my configuration of enforced URLs is the next:
com.sun.identity.agents.config.notenforced.uri[0] = / com.sun.identity.agents.config.notenforced.uri[1] = /-*-.jsp com.sun.identity.agents.config.notenforced.uri[2] = /-*-.jsp* com.sun.identity.agents.config.notenforced.uri[3] = /-*-.jsp?* ... com.sun.identity.agents.config.notenforced.uri.invert = true I enforce all jsps to be validated through SSO. But, what i want to do is to define an URI like:
- If an .jsp is being invoked, but it doesn't have errormsg parameter in it, validate session through SSO;
- But if an .jsp is being invoked and errormsg parameter is in the URL, don't validate it, let it go.
The thing is, can i use regular expressions on SSO URIs? Because those patterns
/-*-.jsp
as far as i know, aren't regular expressions.
How can i create that filter?
1 Answers
Answers 1
You're right in thinking the not enforced list pattern in AMAgent.properties isn't a regular expression. As it seems you've already discovered, it uses a far more limited wildcard matching syntax.
The answer to the question "Can I use regular expressions on SSO URIs?" seems to be no. Unfortunately what can be done here is very limited as the syntax does not include a way of excluding particular characters or phrases. Without further understanding the requirements, my best suggestion would be to use an exclude list rather than an include list:
com.sun.identity.agents.config.notenforced.uri[0] = /-*-.jsp?errormsg* ... (with com.sun.identity.agents.config.notenforced.uri.invert = false)
Of course you may need to add many further entries to this list and it may become large but at least it is more compliant with Oracle's advice:
When the not-enforced list is inverted, the number of resources for which the agent will not enforce access control is potentially very large. The use of this feature should therefore be used with extreme caution and only after extensive evaluation of the security requirements of the deployed applications.
0 comments:
Post a Comment