Protect URLs by JPA-based authorization

[hwellmann.de]

I've looked at various security-related quickstarts like wildfly-quickstart/picketlink-authorization-idm-jpa, but somehow I can't find out how to declare required roles for certain URL patterns,

With Spring Security, I would define patterns like this

    <intercept-url pattern="/search/*" access="hasRole('PERMISSION_SEARCH')" />

    <intercept-url pattern="/manage/*" access="hasRole('PERMISSION_MANAGE')" />

to the effect that when accessing an intercepted URL, my browser would be redirected to a login form, and then redirected to the requested URL on successful authorization.

I don't really care if the solution is based on Picketlink or JAAS or a combination of both, as long as I don't need to leak any application implementation details into the container configuration (like SQL querying my domain model for users and permissions, which is what I've seen in most JAAS examples).

Any pointers appreciated.

Best regards,

Harald

[oortdg]

I hope i've understand your question right but the normal pattern would be add an security constraint to your web.xml

some thing like this:

<web-app>

.....

<security-constraint>

    <display-name>login</display-name>

    <web-resource-collection>

      <web-resource-name>Wildcard means whole app requires authentication</web-resource-name>

      <url-pattern>/search/*</url-pattern>

      <http-method>GET</http-method>

      <http-method>POST</http-method>

    </web-resource-collection>

    <auth-constraint>

      <role-name>PERMISSION_SEARCH</role-name>

    </auth-constraint>

    <user-data-constraint>

      <transport-guarantee>NONE</transport-guarantee>

    </user-data-constraint>

  </security-constraint>

<security-constraint>

    <display-name>login</display-name>

    <web-resource-collection>

      <web-resource-name>Wildcard means whole app requires authentication</web-resource-name>

      <url-pattern>/manage/*</url-pattern>

      <http-method>GET</http-method>

      <http-method>POST</http-method>

    </web-resource-collection>

    <auth-constraint>

      <role-name>PERMISSION_MANAGE</role-name>

    </auth-constraint>

    <user-data-constraint>

      <transport-guarantee>NONE</transport-guarantee>

    </user-data-constraint>

  </security-constraint>

<login-config>

    <auth-method>FORM</auth-method>

    <realm-name>MyRealm</realm-name>

    <form-login-config>

      <form-login-page>/login.html</form-login-page>

      <form-error-page>/login-failed.html</form-error-page>

    </form-login-config>

  </login-config>

  <security-role>

    <role-name>PERMISSION_SEARCH</role-name>

  </security-role>

<security-role>

    <role-name>PERMISSION_MANAGE</role-name>

  </security-role>

....

</web-app>

also you must add an jboss.xml file under the WEB-INF folder

with and security role:

<jboss-web>

      <security-domain>MyRealm</security-domain>

</jboss-web>

and add to the standalone.xml in the security module the query that queried the roles based on the login name and password.

see for example http://middlewaremagic.com/jboss/?p=2187

[hwellmann.de]

Yes, that's the general stuff you see in every Java EE tutorial, but my question really was how to do the container dependent parts on WildFly with either PicketBox or PicketLink or both, and how to avoid application specific SQL queries in a container-level login module configuration (also in the example you linked).

After some experimentation, my conclusions or working assumptions are

• PicketLink does not enter the picture at all.
• I've implemented a custom login module extending UsernamePasswordLoginModule from PicketBox. The module sits inside my WAR and WIldFly has no problem finding it. I was worried about having to create a separate JBoss module for it. I don't even need to include PicketBox in my war, it seems to be an implicit import. My POM includes PicketBox with provided scope
• The login module uses my user/role/permission DAOs based on JPA. I'm working with DeltaSpike's BeanProvider to "inject" the DAOs into the login module.

I'm still unsure whether or not PicketLink is meant to replace PicketBox or whether it's just a solution for different kinds of problems like SSO.