4 Replies Latest reply on Jul 16, 2013 10:52 AM by Bradley Snyder

    Comparing Authentication/Authorization Options

    Bradley Snyder Newbie

      I'm in the middle of developing a REST-based web application for JBoss AS7 and I've reached the point of implementing multi-role user security. It's probably best to outline some high-level requirements:

       

      • Users will be created somehow in the server (or application? preferably server...). They will be assigned Roles (also created in the server).
      • Roles will be in a simple 5-level hierarchy, where the lowest role has read-only access to resources, the middle roles have read-write access, and the top role has read-write plus the ability to manage the user/role system

       

      JBoss as a whole seems to provide several different projects that would let me avoid writing my own authentication/authorization provider that the application then utilizes. I'm going to attempt to summarize what I've found so far, but I am seriously doubting both the accuracy and completeness of this list:

       

      • Built-in JBoss AS7 configuration - using the security domains/realms that comes with an unmodified JBoss AS 7.1.1 installation, all configured in standalone-full.xml and connected in web.xml/jboss-web.xml project files
      • GateIn - This seems to provide a lot of the configuration I'm interested in, but only in the context of portals/portlets. My application at this stage is primarily a back-end that can support any REST client and may in the future provide some sort of front-end on the server.
      • PicketBox - This looks to be a Java SE-oriented project in line with the Java EE PicketLink (greatly oversimplifying here I'm sure)
      • PicketLink - The new home for Seam 3 Security. At this stage this seems to be the most relevant to my goals, but its inclusion in JBoss AS 7 is unclear to me. On one hand I see it in the modules so it seems included, but the PicketLink project itself documents replacing these modules and configuring them as if this is a totally separate add-in. Additionally I do not see any documentation on the AS 7 side acknowledging PicketLink's existence/inclusion.

       

      I'm pretty sure I'm not supposed to be using GateIn or PicketBox to accomplish this. I'm working through both AS7 and PicketLink documentation but wanted to see if there was some intended vision for how this should be done (e.g., if future versions of AS/Wildfly were all going to depend on PicketLink for user management over anything else). Hopefully this all makes sense and I'm understand the purposes of these projects correctly.

        • 1. Re: Comparing Authentication/Authorization Options
          Stephen Coy Master

          The built-in JBossAS 7.x configuration incorporates standard Java EE security. You should check out the "Security" section of the Java Servlet Specification (AS 7.1.x implements the 3.0 version).

           

          This does not incorporate user management, which could potentially be managed externally in an LDAP directory for example. In the LDAP case users are typically placed in directory groups which are subsequently mapped to authorisation roles in the application server configuration.

          1 of 1 people found this helpful
          • 2. Re: Comparing Authentication/Authorization Options
            Bradley Snyder Newbie

            I believe I understand the use of the standard Java EE Security you are pointing me too, although some of the documentation in that Security section does not appear to apply to me since the endpoint code I am writing does not exist in a servlet context, but in @Path annotated JAX-RS interfaces and their implementations.

             

            What I think PicketLink does is provide me with increased functionality in code to manage the users and permissions through an extra deployment. What I think I'm seeing is that if I stick with incorporated Java EE Security, I deploy my WARs/EARs as is, configure security realms or domains in standalone.xml, and configure the WARs/EARs through their web.xml/jboss-web.xml files. I believe PicketLink would work by deploying a separate WAR to JBoss and configuring PicketLink in standalone.xml to control my webapp WARs/EARs. I may be off-base on that, I'm spending some time at the moment to try and stand-up a demo example of this and see what I can learn.

            • 3. Re: Comparing Authentication/Authorization Options
              Stephen Coy Master

              It's worth reading the JAX-RS specification too. That leads me to believe that there is most definitely a servlet context.

              • 4. Re: Comparing Authentication/Authorization Options
                Bradley Snyder Newbie

                Already in working through some PicketLink documentation, it looks like I may be off-base a little bit. I think the key here (for me) is that part of what I'm developing intends to provide REST methods for the top-user to add/remove users to the system and change their roles. The Java EE Security setup seems to treat the security domain as a static, externally-managed entity. In that case, in your LDAP example, I would be able to configure the application to approve/deny requests at elevated privileges based on the roles, but I wouldn't be able to modify these without directly accessing the LDAP outside of my application. This is doable, but not quite what I'm looking to accomplish.

                 

                GateIn seems to provide a built-in ability to manage these users and roles either through a management GUI or through code that calls API functions, but all of these seems restricted to its portal context which I haven't been developing to.

                 

                I think you're correct that there's a servlet-context in JAX-RS. If you don't use the @ApplicationPath annotation and activate JAX-RS in web.xml, it's using servlet configuration type functionality to do it. I believe that its a subset (I'm not sure I can annotate REST endpoints with @ServletSecurity for example) but that's not 100% clear, and I still need to read through the JAX-RS spec.