1 2 3 Previous Next 30 Replies Latest reply: Dec 5, 2006 2:37 PM by Anil Saldhana RSS

Generalizing the JACC service

Scott Stark Master

So with the introduction of a pluggable authorization service for the j2ee 1.4 JACC requirement, we have opened up the possibility of having a very general authorization decision service. One main problem with the existing service is that it has no extensibility in terms of what permissions have been assigned to roles with a given context.

I talked to Abhijit Belapurkar at JavaOne about an implementation he did based on the XACML implementation from Sun and will work with him on at least getting this into the codebase as a testcase of alternate implementation to avoid the implementation details assumptions from leaking into the security aspects on top of JACC. I do want to look at moving to a default JACC provider that is built on XACML as the current overloading of the JAAS authentication phase to provide the declarative roles is too limiting.

This topic is the start of discussion on what needs to be done to move to the next generation of JACC implementation, and more generally the next generation of authorization service.

I don't expect to get too much done for a month as I'm focused on finalizing 4.0.3 and there is vacation time on the horizon.

  • 1. Re: Generalizing the JACC service
    Abhijit Belapurkar Newbie

    I essentially started with the "in-memory" JACC provider that comes out-of-the-box with JBoss 4.0.2 and enhanced it to include the mapping between the JACC Permission classes and the corresponding XACML constructs. (So, for example, the commit method was enhanced to include code for generating the XACML policy sets etc.)

    In my version of the provider, I've used the open source XACML implementation from Sun (http://sunxacml.sourceforge.net) as the underlying framework for the XACML constructs. This framework
    provides, out-of-the-box, a very simple file-based policy finder module (intended for use only as a sample). I?m using this finder in my JACC provider. So, the XACML policy set(s) for applications are written out into flat files during app deployment; these files are then searched at policy enforcement time. A file-based approach is clearly not the most performant/scalable of options, and needs to be reworked.

    An aside: while testing my provider, I noticed that unchecked WebUserDataPermission instances were not being generated for a deployed application as expected. Briefly, the problem seems to be as follows. Line # 180 of the file "WebPermissionMapping.java" reads while (roles.hasNext()). However, this loop is always skipped, since the roles Iterator is never re-initialized after the previous loop (line # 157) has completed its run.

    At first glance, it would seem that the way to fix this is to change line #179 to read roles = info.getTransportMethods(). However, after having made that change, I found that unchecked WebUserDataPermission instances were certainly getting generated, but not all of them seemed to be quite the right ones I was expecting. I've not had a chance to follow up on this point since. This needs to be revisited, to confirm whether there is indeed a problem.

  • 2. Re: Generalizing the JACC service
    Thomas Cherel Novice


    There is a very good chance that you guys already thought about that, but just in case....

    I think that the way you can dynamically (at login time) define the roles of a user by creating a custom JAAS login module is very useful.
    An very often, this is all that is needed.
    I understand that a custom JACC provider can do more, but I think it will be a pain if a full blown provider (or a full blown set of custom JACC policy) has to be defined if the only thing that is needed is to be able to specify what are the roles of a given user.

    May be the future default JBoss JACC provider should have multiple extension points (JBoss specific) where a user can simply overwrite the way roles are retrieved for a user, the way roles are associated to resources and the way permissions are checked (or something like that).
    Users will then be able to easily "pick and choose" which part of the default JACC provider they want to customize for their needs.

    Thomas

  • 3. Re: Generalizing the JACC service
    Scott Stark Master

    Of course, that is the jboss way.

  • 4. Re: Generalizing the JACC service
    Woodler Expert

    What about a JACC module descriptor similar to login-config.xml ? Or even make JACC a part of login-config.xml ? After all it seems that the login module and the jacc module have to work together. JACC modules could have a contract similar to JAAS modules (stackable etc.), and should be just as easy to configure per application.
    I'd also like to mention that this module should allow to be extended to cover access control checks for things like portal resources, or workflow processed, etc, so that multiple PEP interceptors could call into one central PDP (via the JACC impl). I have a document written up describing one possible way (based on the 4.0.2 jacc implementation classes) that I could forward you if you are interested.

  • 5. Re: Generalizing the JACC service
    Scott Stark Master

    Yes send the doc so it can be incorporated into this thread.

  • 6. Re: Generalizing the JACC service
    Woodler Expert

    here is the short of it:

    1) requirements and goals:
    * JACC implementations need to be pluggable similar to JAAS modules
    * JACC modules need to be configurable per application
    * the current JACC implementation needs to be extended to allow other then J2EE resources to check access control through the same mechanism (portal resources for instance)
    * the JACC module should allow for more dynamic features , such as access check for portal pages that were created after the portal was deployed
    * all JEMS components need to use a unified way to check access control (through JACC; to allow easy configuration of a single PDP)
    * static role assignment (in the login module) imposes too many restrictions (think: user is in role 'bookkeeper' from 9 to 5 only). As a result, for more advanced security scenarios, the JACC provider needs to be the one that handles role memberships (dynamically)

    2) implementation details:
    * JACC modules can be written against a defined API (SPI) that would need to be created
    * JACC modules can be configured per application (login?config.xml ?)
    * JACC modules could potentially be stackable ((static)J2EE module, Portal module, jBPM module, custom module...) similar to (but far more flexible then) DelegatingPolicy
    * container code (interceptors) checks access via an abstracted API
    very simplified:

     Security.implies(permission type, subject, resource, action)
    

    where permission type is one of J2EE, Portal, ....

    * deployers can discover the configured JACC module and add the correct permissions
    * all permission types extend java.security.Permission
    * the abstracted API news up the correct Permission class (based on the permission type) and calls into a deeper layer
    * this deeper layer reads the configured JACC module(s), loads them, and performs the access check with them
    * the JAAS and JACC modules need to share some state to allow the JACC provider to get to SAML assertions etc. This would potentially be done via special principals in the subject
    * if no JACC provider is configured for an app, the JBoss default one is used

    3) questions and food for thought:
    * during our discussion around this topic we realized that most applications up the stack (Portal, BPM, WSRP, ...) all need to handle "identity as data" as well. Meaning: they all need to access user attributes in one form or another. We believe that this topic needs to be considered as well when we try to solve JAAS, JACC , RBAC , SAML,... in this layer.


  • 7. Re: Generalizing the JACC service
    Scott Stark Master

    Yes, we do need the ability to configure the jacc modules per application. Part of this is a much better notion of correlating the jacc policy context id with a deployment. Today its based on the deployment jar, but there needs to be support for externalization of this id for easy correlation with the external security stores.

    We do need a coupling of the authentication and authorization layers through the authentication Subject. Today we do not support a notion of being able to authenticate, and using only the Subject, execute as the subject. It would require a custom login module that could validate that the doAs Subject is in fact one that has been authenticated, and still has a valid cache state.

  • 8. Re: Generalizing the JACC service
    Thomas Cherel Novice

    If I may add a few possible requirements on the coupling between authentication and authorization (and related):

    1) Definitely allow a doAs model on an EJB client application. This should allow a singel application to authenticate multiple users (if needed) and decide which user to use when and for which operations (quite useful in multi-tiers environments).

    2) But doAs model can sometime be painful to program with (delegate class needed for all actions). There should be a way to also set the "current subject" for the current thread or for all threads (or groups or all JVM) to make single-user application easy to write.

    3) Being able to configure the server so java security is actually enforced (all actions executed on the server side are done within a doAs block). This will allow java security policies to be defined on the server side if needed.

    4) A tighter integration between the client JAAS login modules and the server ones will be nice:
    - Calling LoginContext.login on the client should go through the client side JAAS modules, then subject is sent to the server and server side JAAS modules are then executed.
    - Any custom principal (or credential or others) added to the Subject during client side authentication should be available in the Subject provided to the server side JAAS modules.
    - Any custom principal (or credential or others) added to the Subject during server side authentication should be available in the Subject on the client side after authentication process is finished. May be a configurable mechansim to decide what is "sent back" or not will be nice as well.

    5) Probably linked to point 3) above, being able to retrieve the current subject in any EJB component code (like within a session bean operation).


    All these requirements have one goal in mind: making authentication/authorization more flexible and "easily" customizable.
    At least these are the kind of things I would have loved to see in one of my recent project :-)

    I think similar flexibility should also be provided through the web container. My understanding in this area is not as good as on the pure EJB client, so it is harder for me to define some precise requirements, but some of the ideas are as follow:

    1) Being able to get the current Subject in servlet code, including any custom principals (or others) that have been added to it.

    2) Some FORM authentication extensions where extra form fields (or even HTTP headers) can be used for the authentication process (can be accessed in the JAAS login module). Something that will allow similar custom authentications that can be done with custom subject principals sent from the client.

    I also have a few more ideas that I need to formalize a little better arround SSO capabilities.
    Basically, with some of the JDK provided login modules (NTSystem, Kerberos and Unix), it should be possible to support SSO from an EJB client without too much pain. What I mean by SSO is being able to propagate the id from the current user of the client machine (Unix or windows user id) without having to ask the user to provide user name and password again (he already did it when login to his machine).

    Thomas


  • 9. Re: Generalizing the JACC service
    ErikEngerd2 Newbie

    Hi,


    Just had a look at the JACC specification and one thing I noticed is that this interface is a bit specific towards role based security and supporting the role based security model of J2EE. In addition, we also need a method for supporting JAAS based authorization in J2EE applications. That is, where the application defines custom security Permissions for itself.

    Just to give an example, I am considering to write a J2EE application that uses custom Permission objects to represent permissions to resources. The security model behind it might or might not be based on role based security. In other words, what I need is a custom set of Policy rules for a J2EE application in addition to those rules already in effect in my environment. This wouldn't be done in the form of a Policy replacement, of course, since it should be impossible to override server policies, but still a mechanism for this is needed.

    If I am correct, JACC only addresses the problem of supporting the current J2EE security model through JAAS and this aim is insufficient for my application.

    Cheers
    Erik

  • 10. Re: Generalizing the JACC service
    piratepete Newbie

    Scott:

    I've been looking at this for personal reasons (lol, trying to convince Ivelin to hire me) but I wrote an article for TSS on SAML and my desire is to create a SAML server and complete administration app for JBoss.

    I like that SAML could be used to communicate these "identity" things, but my thoughts are to use e.g. HSQL to house the identity data, provide an administration thereof, and use SAML with JAAS to do multi-domain authenticates and authorization for businesses.

    I have been thinking of using combination JAAS with a SAML identity service but if extending JAAS across contexts is possible, that would be better. In any event, "descripted" security for multi-domain identity management would be sweet. It's possible I think.

    I recently took a job to lead a large project using BEA WebLogic servers but I would like solve this one (extended JAAS, SAML, etc. multi-domain identity management) using JBoss using only J2EE (complete non-proprietary). I'll keep posting here, since Ivelin pointed me in the right direction. My article on TSS is here http://www.theserverside.com/articles/article.tss?l=SAML Take a look, it's somewhat mousetrap but I understand what the problem is, I just haven't found the exact solution yet.

    piratepete aka (David Whitehurst)

  • 11. Re: Generalizing the JACC service
    Anil Saldhana Master

    http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3890653#3890653

    is a good place to discuss SAML, Identity Management and JBoss. :)

  • 12. Re: Generalizing the JACC service
    Scott Stark Master

    So the DelegatingPolicy used as part of the default jboss jacc provider has been extended to support a set of external permissions specified via the ExternalPermissionTypes:

     <mbean code="org.jboss.security.jacc.DelegatingPolicy"
     name="jboss.security:service=JaccPolicyProvider"
     xmbean-dd="">
     <xmbean>
     <attribute access="read-only" getMethod="getPolicyProxy">
     <description>The java.security.Policy implementation</description>
     <name>PolicyProxy</name>
     <type>java.security.Policy</type>
     </attribute>
     <attribute access="read-write" getMethod="getExternalPermissionTypes"
     setMethod="setExternalPermissionTypes">
     <description>The types of non-javax.security.jacc permissions that
     should be validated against this policy</description>
     <name>ExternalPermissionTypes</name>
     <type>[Ljava.lang.Class;</type>
     </attribute>
     <operation>
     <name>listContextPolicies</name>
     <return-type>java.lang.String</return-type>
     </operation>
     </xmbean>
     <!-- Not used, just here to test that custom permissions don't break the
     current behavior of javax.security.jacc.* permissions.
     -->
     <attribute name="ExternalPermissionTypes">org.jboss.security.srp.SRPPermission</attribute>
     </mbean>
    


    This is in the 4.0 codebase for 4.0.3 but won't be a documented feature until 4.0.4. Deployers can introduce custom permissions that associated security interceptors enforce and use the default jboss jacc provider in a somewhat pass-through manner.

    A usecase where a null ProtectionDomain was passed to the jacc Policy came up and this is not handled gracefully today. The question is what meaning should be attached to a null ProtectionDomain. One suggestion was that the PolicyContext subject should be consulted. This I do not agree with.

    Another alternative would be some guest identity similar to the unauthenticatedIdentity notion supported by the login modules. Another is to simply fail, albeit more gracefully than an NPE, as identity is not the responsibility of the jacc provider.


  • 13. Re: Generalizing the JACC service
    Scott Stark Master

     

    "piratepete" wrote:
    Scott:

    I've been looking at this for personal reasons (lol, trying to convince Ivelin to hire me) but I wrote an article for TSS on SAML and my desire is to create a SAML server and complete administration app for JBoss.

    I like that SAML could be used to communicate these "identity" things, but my thoughts are to use e.g. HSQL to house the identity data, provide an administration thereof, and use SAML with JAAS to do multi-domain authenticates and authorization for businesses.

    I have been thinking of using combination JAAS with a SAML identity service but if extending JAAS across contexts is possible, that would be better. In any event, "descripted" security for multi-domain identity management would be sweet. It's possible I think.

    I recently took a job to lead a large project using BEA WebLogic servers but I would like solve this one (extended JAAS, SAML, etc. multi-domain identity management) using JBoss using only J2EE (complete non-proprietary). I'll keep posting here, since Ivelin pointed me in the right direction. My article on TSS is here http://www.theserverside.com/articles/article.tss?l=SAML Take a look, it's somewhat mousetrap but I understand what the problem is, I just haven't found the exact solution yet.

    piratepete aka (David Whitehurst)


    The problem today is that identity today, and even authentication is way too underspecified to have any truly portable security solution in J2EE(Java EE now) servers. Without support of something like the JSR-196 authentication contract there will be nontrivial server specific integration, and security scenarios that don't map well because they are underspecified in the specs.


  • 14. Re: Generalizing the JACC service
    Zulfi Umrani Newbie

     

    "scott.stark@jboss.org" wrote:
    So the DelegatingPolicy used as part of the default jboss jacc provider has been extended to support a set of external permissions specified via the ExternalPermissionTypes:

     <mbean code="org.jboss.security.jacc.DelegatingPolicy"
     name="jboss.security:service=JaccPolicyProvider"
     xmbean-dd="">
     <xmbean>
     <attribute access="read-only" getMethod="getPolicyProxy">
     <description>The java.security.Policy implementation</description>
     <name>PolicyProxy</name>
     <type>java.security.Policy</type>
     </attribute>
     <attribute access="read-write" getMethod="getExternalPermissionTypes"
     setMethod="setExternalPermissionTypes">
     <description>The types of non-javax.security.jacc permissions that
     should be validated against this policy</description>
     <name>ExternalPermissionTypes</name>
     <type>[Ljava.lang.Class;</type>
     </attribute>
     <operation>
     <name>listContextPolicies</name>
     <return-type>java.lang.String</return-type>
     </operation>
     </xmbean>
     <!-- Not used, just here to test that custom permissions don't break the
     current behavior of javax.security.jacc.* permissions.
     -->
     <attribute name="ExternalPermissionTypes">org.jboss.security.srp.SRPPermission</attribute>
     </mbean>
    


    This is in the 4.0 codebase for 4.0.3 but won't be a documented feature until 4.0.4. Deployers can introduce custom permissions that associated security interceptors enforce and use the default jboss jacc provider in a somewhat pass-through manner.

    A usecase where a null ProtectionDomain was passed to the jacc Policy came up and this is not handled gracefully today. The question is what meaning should be attached to a null ProtectionDomain. One suggestion was that the PolicyContext subject should be consulted. This I do not agree with.

    Another alternative would be some guest identity similar to the unauthenticatedIdentity notion supported by the login modules. Another is to simply fail, albeit more gracefully than an NPE, as identity is not the responsibility of the jacc provider.


    I agree that we need to attach appropriate meaning to null ProtectionDomain(PD). I am not the expert on the subject, but it looks like that ProtectionDomain is part of legacy Policy API which is carried forward into JACC. Except Principal[], JACC does not care about other properties of PD. Moreover, from the application's point of view, if it is doing dynamic resources/permissions, it relies on the container to find the appropriate Subject/Identity of the user. From that perspective a null PD could mean that the container should get one for the application. Without container finding the identity, the application will be forced to create a dummy PD containing Principal[] from the PolicyContext. Though it is possible, but from the application's perspective it is cumbersome to do do. Hence I feel that if PD is null then the JACC layer should find the appropriate Identity/Subject.


1 2 3 Previous Next