I accessed the page protected by ADF security using direct url access attac

Question

hi,
I played with my application which is based on SRDemo code (with added ADF security handling protection of resources) using direct url access scenarios. I was able to access a protected page as authenticated but not authorized user. I'll try to explain what I did.
There are two folders/web resources in my application, faces/folderA/* and faces/folderB/*.
roleA only is configured to access first web resource and the roleB is configured to access the second resource.
I used ADF security to authorize only roleA for page in folderA and to authorize only roleB for page in folderB.
I configured error pages in web.xml:
<error-page>
<error-code>400</error-code>
<location>faces/error/error400.jspx</location>
</error-page>
<error-page>
<error-code>401</error-code>
<location>faces/error/error401.jspx</location>
</error-page>
<error-page>
<error-code>403</error-code>
<location>faces/error/error403.jspx</location>
</error-page>
<error-page>
<error-code>404</error-code>
<location>faces/error/error404.jspx</location>
</error-page>
<error-page>
<exception-type>java.lang.Throwable</exception-type>
<location>faces/error/error500.jspx</location>
</error-page>
Other config params are:
<login-config>
<auth-method>FORM</auth-method>
<form-login-config>
<form-login-page>infrastructure/ABLogin.jspx</form-login-page>
<form-error-page>faces/error/error401.jspx</form-error-page>
</form-login-config>
</login-config>
<security-constraint>
<web-resource-collection>
<web-resource-name>AB Prototype</web-resource-name>
<url-pattern>faces/ABAbout.jspx</url-pattern>
<url-pattern>faces/ABHelp.jspx</url-pattern>
<url-pattern>faces/ABLogout.jspx</url-pattern>
<url-pattern>faces/ABWelcome.jspx</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>A</role-name>
<role-name>B</role-name>
</auth-constraint>
</security-constraint>
<security-constraint>
<web-resource-collection>
<web-resource-name>AZone</web-resource-name>
<url-pattern>faces/folderA/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>A</role-name>
</auth-constraint>
</security-constraint>
<security-constraint>
<web-resource-collection>
<web-resource-name>BZone</web-resource-name>
<url-pattern>faces/folderB/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>B</role-name>
</auth-constraint>
</security-constraint>
<filter>
<filter-name>adfBindings</filter-name>
<filter-class>oracle.adf.model.servlet.ADFBindingFilter</filter-class>
<init-param>
<param-name>unauthorizedErrorPage</param-name>
<param-value>faces/error/error401.jspx</param-value>
</init-param>
</filter>
<filter>
<filter-name>adfFaces</filter-name>
<filter-class>oracle.adf.view.faces.webapp.AdfFacesFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>adfBindings</filter-name>
<url-pattern>*.jsp</url-pattern>
</filter-mapping>
<filter-mapping>
<filter-name>adfBindings</filter-name>
<url-pattern>*.jspx</url-pattern>
</filter-mapping>
<filter-mapping>
<filter-name>adfFaces</filter-name>
<url-pattern>*.jsp</url-pattern>
<dispatcher>FORWARD</dispatcher>
<dispatcher>REQUEST</dispatcher>
<dispatcher>ERROR</dispatcher>
</filter-mapping>
<filter-mapping>
<filter-name>adfFaces</filter-name>
<url-pattern>*.jspx</url-pattern>
<dispatcher>FORWARD</dispatcher>
<dispatcher>REQUEST</dispatcher>
<dispatcher>ERROR</dispatcher>
</filter-mapping>
<servlet>
<servlet-name>Faces Servlet</servlet-name>
<servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet>
<servlet-name>resources</servlet-name>
<servlet-class>oracle.adf.view.faces.webapp.ResourceServlet</servlet-class>
</servlet>
<servlet>
<servlet-name>adfAuthentication</servlet-name>
<servlet-class>oracle.adf.share.security.authentication.AuthenticationServlet</servlet-class>
<load-on-startup>2</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>Faces Servlet</servlet-name>
<url-pattern>/faces/*</url-pattern>
</servlet-mapping>
Once I authenticated as user in roleA I was trying to directly access URLs accessible only by users in roleB. In the beginning everything worked OK: I was dispatched to error401.jspx page with message Not authorized... etc.
But I kept trying to access different URLs, like http://localhost:8988/AB/faces, http://localhost:8988/AB/faces/folderB, http://localhost:8988/AB/faces/folderB/pageB.jspx, http://localhost:8988/AB
(not necessarily in that order, I played for a couple of minutes and the system would always dispatch to error401.jspx page if unauthorized attempt. But all of sudden, to my surprise, I got the pageB.jspx page while logged in as user belonging to roleA!)
Not sure how that happened but the connectedUser on pageB (#{userInfo.authenticated}) shows that I am logged in as user whose role is A.
I checked Authorization in ADF security and it is still correct: pageB is only accessible to roleB and pageA is only accessible to roleA.
I hope I made some stupid mistake in my configuration?

Answer 1

Hi,
ADF Security is JAAS permission based and not container managed. Note that unless you explicitly configured ADF Security you don't use ADF Security but container managed security, which is all that I can see in your configurations.
Not sure which version fo JDeveloper you use, but if you could change the following setting
<security-constraint>
<web-resource-collection>
<web-resource-name>AZone</web-resource-name>
<url-pattern>faces/folderA/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>A</role-name>
</auth-constraint>
</security-constraint>
<security-constraint>
<web-resource-collection>
<web-resource-name>BZone</web-resource-name>
<url-pattern>faces/folderB/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>B</role-name>
</auth-constraint>
</security-constraint>
to contain jspx file references instead of wildcards like in faces/folderB/* then what you see should no longer be possible. There was a known issue with the security settings in SRDemo that was caused by a defect in OC4J container managed security. I would expect this issue to be fixed in a more recent version of OC4J.
However, the work around until then is to protect all JSPX files in a directory instead of using wild card matches
Frank