PicketLink vs Standard security

[blabno]

Hello,

1. How is PicketLink related to standard security mechanisms of JEE?

When I read JEE tutorial security is configured outside of app (i.e. login modules) and user i authenticated on every request if requested resource is constrained in web.xml.

In seam2 and seam3 we kept Identity object inside session and used CDI interceptors attached to beans or their methods.

2. Is it possible to use PicketLink without CDI and still be able to reuse @RolesAllowed annotation?

3. How can I use PicketLink to login and then associate request with principal from PicektLink?

[shane.bryzak]

Hi Bernard,

1. How is PicketLink related to standard security mechanisms of JEE?

When I read JEE tutorial security is configured outside of app (i.e. login modules) and user i authenticated on every request if requested resource is constrained in web.xml.

In seam2 and seam3 we kept Identity object inside session and used CDI interceptors attached to beans or their methods.

PicketLink is essentially the successor to Seam Security, so the fundamental architecture should already be familiar if you've used Seam before.  The base PicketLink module provides a session-scoped Identity bean which fulfills the same purpose as the Identity bean in Seam.

2. Is it possible to use PicketLink without CDI and still be able to reuse @RolesAllowed annotation?

You can use the IDM module of PicketLink without CDI (it was designed to work in a JavaSE environment) however if you're in JavaEE you'll need to then do all the wiring yourself.  It currently does not work with the @RolesAllowed annotation, instead we recommend you use the security annotations from DeltaSpike - you can see an example of this in one of the PicketLink quickstarts:

https://github.com/picketlink/picketlink-quickstarts/tree/master/picketlink-deltaspike-authorization

3. How can I use PicketLink to login and then associate request with principal from PicektLink?

There's quite a few quickstarts that deal with authentication, I suggest you take a look at those (link below).  As described above, the "principal" is stored in the session-scoped Identity bean so once the user is authenticated the Identity bean will always be available for injection until the user's session times out or they log out.

https://github.com/picketlink/picketlink-quickstarts

[blabno]

Shane, Thank you very much for quick reply.

whining:

In early days of Seam3 I was fan of CDI but I was disappointed with cancellation of Seam3 project and slow DS development. Besides CDI is so slow on deploy, especially when extensions kick in.

Well, CDI is cool for statefull apps, like JSF based stuff, but in case of stateless architecture like in REST+AngularJS pure EJB are is enough and I don't see added value of CDI.

standard = string-typing:

What I like about standard JEE security is that I can annotate both REST resource bean with @RolesAllowed or other standard annotations and do the same with EJB's in business layer.

The only problem right now for me is that some REST resources should be available for anonymous users and some need authentication. It requires for me to specify all URL's in web.xml which is slippery "string-typing".

In case of such API it's impossible to specify security constraints in web.xml:

GET /user/1 - get profile data (available for anonymous)

GET /user/1/private - get private user data (only authenticated user)

CDI interceptors attached to resource methods would bring strong-typing (significantly reducing number of required security tests). But if PicketLink works same as in Seam then we won't be able to call ejb.SessionContext.getUserPrincipal() or HttpServletRequest.getUserPrincipal(), or am I wrong?

oh, that stateless nature:

Other thing is that in case of REST services I think we should not rely on session as it's nature is stateless and users may do each request without keeping cookie or whatever else to mark state.

Also when user wants to access secured resource then in case of picketlink-authorization-rs-rbac (DS+PicketLink) they must do 2 requests, first to authenticate and second (within same session) to access actual resource.

In case of standard JEE BASIC auth configured within container user needs only one request with Authorization header.

security at which level:

I think that security should be defined on business layer, not on web layer (REST resources). Same EJB could be accessed via remote interface or REST resource.

is standard dead:

I always loved ideas and inventions of JBoss teams as they were very useful and were solving real problems. It looks to me like standard JEE security had good intentions (taking big part of security related stuff out of application), but is way to limited and hence the PicketLink and other solutions. Now my natural instinct says on one hand "stick to standards" and on the other "those JBoss guys know what they are doing". PicketLink seems to duplicate things that should be already in container: picketlink-authentication-rs-endpoint/src/main/java/org/jboss/as/quickstarts/picketlink/authentication/rest/CustomAuthenticator.java. To me this is something that should be a LoginModule.

So which direction will security evolve in?