7 Replies Latest reply: May 19, 2011 12:33 AM by Grigori Goldman RSS

Recommendations for securing a CDI Java EE 6.0 app?  (replacement for Spring Security)

Steven Boscarine Novice

Hello All,

I am working on a fairly large scale Java EE 6.0 web-profile application that uses JSF, CDI, EJB (war), JPA, JAX-RS, etc.  I am relatively new to Java EE 6 and was wondering if anyone had recommendations on securing the application. 


Which technologies would you recommend I investigate?  How close is Seam 3 Security to being ready to use?  Is standard Java EE 6.0 security a good choice? (http://java.sun.com/javaee/6/docs/tutorial/doc/bncas.html)


Which forums would you recommend I ask questions in (if I run into them)?  Since this is a concern that broadly applies across the Java EE platform, it may not be ideal to post in a JSF or Weld forum. 


My application  is in the healthcare domain, so security is an essential concern.  For past applications, I have used both Seam 2.x Security and Spring Security and loved the method-level annotations.  I would want to apply annotations to methods on my weld and EJB components. 


The most challenging piece I need to model is limiting a method call to the owner of a record.  For example, my app models a doctors visit.  I need to prevent everyone but the original doctor or the patient from calling methods that modify the medical record for the visit. 


I know Java EE has @RolesAllowed, but it is limited to static roles, right?  I can declare a method to be only executable by the site-wide role, like ADMIN, but I have no way of securing a method with a contextual role so that I can accept/reject a call to a method based on a call to a separate method that would look up custom business logic to determine if the user who is logged in is of a role for this specific object, right? 


Does anyone have recommendations on securing a method with a contextual role?


Thanks in advance,

Steven

  • 1. Re: Recommendations for securing a CDI Java EE 6.0 app?  (replacement for Spring Security)
    Pete Muir Master

    Shane has made a start on Seam Security 3. You can expect to see some really active development starting in about a week - Shane is meeting with Anil this week (who is our security top-dog for JBoss Middleware) to try to work out how to align the identity, and auth* stuff in JBoss AS with Seam.

  • 2. Re: Recommendations for securing a CDI Java EE 6.0 app?  (replacement for Spring Security)
    Matthieu Chase Heimer Newbie

    With traditional Java EE security you'd have to use programmatic checking within the method. You'd lock down the UI tier and then the security context info would propagate to the EJB tier. At that point you could then use:  Securing an Enterprise Bean Programmatically.

  • 3. Re: Recommendations for securing a CDI Java EE 6.0 app?  (replacement for Spring Security)
    Dan Allen Master

    A good security API is one of the most significant gaps that still remains in Java EE. While JAAS certainly has some merit, it's:



    • Too difficult to setup (in a portable way)

    • Is not contextual (decision-based rules and ACLs)



    The short answer is, you need Seam Security. Fortunately, it's coming soon. Shane said in the team meeting today The features from Seam 2 have been ported over and it compiles. It just doesn't have tests yet. We talked about the urgency of having a beta out there in the wild for developers like yourself to start using, so the ball is rolling.


    There's even better news! The Seam team is joining forces with the security team at JBoss (PicketLink) to fill in the federated/SSO/OpenID security needs. So not only will you have the simple Seam security API that supports role-based, rule-based and ACLs, you'll also have the ability to put that security under a single identity umbrella. That integration won't hold back the beta of the Seam Security module.


    The Seam Security module will also depend on the XML configuration module, because you'll have to tune some of the parameters to get Seam Security to connect to your authentication source.

  • 4. Re: Recommendations for securing a CDI Java EE 6.0 app?  (replacement for Spring Security)
    Stuart Douglas Master

    The seam-xml module will allow portable extensions to register custom namespace handlers, so all PE's can have their configuration in the one place.


    If a module provides a configuration API then it will be possible to create a bridging module to handle xml configuration, without introducing any dependencies between the modules.


    Also this will allow the mixing of different xml formats, so it could support the legacy component.xml format for the seam2 bridge, all in the same file.

  • 5. Re: Recommendations for securing a CDI Java EE 6.0 app?  (replacement for Spring Security)
    Steven Boscarine Novice

    Thank you for your responses.  I would certainly like to use Seam Security, but my deadline may come before it gets finalized.  I may be able to slip it in via a follow up release. 


    If I am running Weld in Java EE6 (on glassfish v3 web), what security annotations are available within Weld? 


    I noticed @RolesAllowed works in an EJB, but not in a CDI bean.  Is that a mistake on my part or is that an actual limitation?


    I noticed that if I assign a <security-constraint> and <login-config> in the web.xml, it works great.  If a user request a page that requires a login, they'll be prompted to enter their credentials and redirected to the original page upon authentication and authorization.  For the @RolesAllowed annotated EJB methods, the system just throws an exception till you login. 


    Is there a way to get my container to redirect them to a login page when a secured method is called?, the way Spring Security does with @RolesAllowed, or a page defined in a <url-pattern> in a <security-constraint> does?  If so, does anyone have suggestions on where to find examples?


    Thanks!!

    Steven






  • 6. Re: Recommendations for securing a CDI Java EE 6.0 app?  (replacement for Spring Security)
    Dan Allen Master

    If I am running Weld in Java EE6 (on glassfish v3 web), what security annotations are available within Weld? 


    Weld doesn't add anything special with security, so the annotations available will be the annotations from Java EE 6. Which are...



    I noticed @RolesAllowed works in an EJB, but not in a CDI bean.  Is that a mistake on my part or is that an actual limitation?


    I know what you mean when you say CDI bean, but I'm going to clarify for someone else reading this, offer an alternate terminology, then get to the answer.


    There are really two types of beans, EJB or managed. CDI represents the services added to those beans. Let's call those CDI enhanced beans. Security annotations are provided by EJB, not by managed beans. So in short, you must use an EJB for this feature.



    I noticed that if I assign a <security-constraint> and <login-config> in the web.xml, it works great.  If a user request a page that requires a login, they'll be prompted to enter their credentials and redirected to the original page upon authentication and authorization.  For the @RolesAllowed annotated EJB methods, the system just throws an exception till you login. 

    Is there a way to get my container to redirect them to a login page when a secured method is called?, the way Spring Security does with @RolesAllowed, or a page defined in a <url-pattern> in a <security-constraint> does?  If so, does anyone have suggestions on where to find examples?


    You could use the servlet exception handler in web.xml. However, I don't think it's easy to redirect the user back to the original page without some experimentation.

  • 7. Re: Recommendations for securing a CDI Java EE 6.0 app?  (replacement for Spring Security)
    Grigori Goldman Newbie

    I know this is an old thread but just in case someone stumbles across it...


    Does it really makes sense to redirect the user to the login page if the system throws an exception as a result of a failed EJB method invocation due to a security constraint?


    I think not. The fact that your request is getting through to the EJB in the first place implies that your user is already authenticated but does not have permissions to execute a particular method, hence asking the user to login again will not help (unless they log in as someone else somehow...).


    That's my five cents worth anyway.


    Probably not the answer you were looking for though...


    Regards,
    Grigori