Details

    • Type: New Feature New Feature
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Component/s: None
    • Labels:
      None

      Description

      The current state of Java EE (Java EE Security, JAAS, JASPIC, etc) is geared towards defining application security constraints and security provider vendor pluggability. Actual identity stores and role mapping is left non-standard.

      This model is certainly viable in the case where these concerns need to be administered outside the application and role mapping is complex. The model also works well in allowing application server vendors to provide a broad range of features/security providers (and they clearly generally do). The main shortcoming of the model is that it leaves important parts of the application non-standard/non-portable, even for very simple, well-understood, widely used cases. Having to learn non-standard features also makes things more difficult for Java EE beginners. Perhaps most importantly, this model is problematic in cloud/PaaS environments where developers do not necessarily have easy access to non-standard vendor runtime features and a self-contained application is much easier to manage.

      A simple way to address these issues is standardizing a small number of annotations to configure identity stores that make some simplifying assumptions such as simple role mappings and only targeting the most common types of identity stores. In fact, most application servers like Resin, JBoss and GlassFish already provide these sorts of simple identity stores.

      As a basic starting point, I suggest identity stores for embedded security data, database storage and LDAP storage. Here are some examples:

      @EmbedddedIdentityStore(
        {@Credentials(username="reza", password="secret", roles="dad"),
         @Credentials(username="nicole", password="secret", roles="mom"),
         @Credentials(username="zehra", password="secret", roles="daughter"),
         @Credentials(username="xavier", password="secret", roles="son")})
      

      This type of identity store is very useful for small prototype/RAD applications as well as unit/integration tests. Besides embedding user credentials, they could also be stored in XML, JSON, YAML or property files.

      @DatabaseIdentityStore(
          lookup="somedatabase", 
          userQuery="SELECT password FROM principals WHERE username=?", 
          rolesQuery="SELECT role FROM roles where username=?", ...)
      
      @LdapIdentityStore(url="...", dnPrefix="...", dnSuffix="...", ...)
      

      These simple stores could work additively with containers that already provide non-standard security providers, especially to cover cases beyond the very simple such as OAuth, OpenID, SAML, etc a well as complex role mapping.

        Activity

        Hide
        reza_rahman added a comment -

        Do let me know if anything needs to be explained further - I am happy to help.

        Please note that these are purely my personal views and certainly not of Oracle's as a company.

        Show
        reza_rahman added a comment - Do let me know if anything needs to be explained further - I am happy to help. Please note that these are purely my personal views and certainly not of Oracle's as a company.
        Hide
        arjan tijms added a comment - - edited

        Very, very much in favor of this!

        I see two possible variations of the requested functionality:

        1.

        The proposed annotations map transparently to whatever proprietary identity stores the application server is already using. If a given AS doesn't already have a matching store it has to implement it of course.

        This will work very well with the build in authentication mechanisms (aka the messaging method, meaning how and via what way the authentication dialog with the user takes place), such as FORM, BASIC, DIGEST and CLIENT-CERT in Servlet, and most likely with the undefined concept of the EJB security domain as well. This will however not do anything for custom authentication mechanisms, e.g. those implemented via JASPIC.

        2.

        The proposed annotations map to predefined implementations of the kind of module/provider that was proposed for JAVAEE_SPEC-9 and JAVAEE_SPEC-25. These implementations can of course just wrap any existing proprietary identity store that already exist in a given AS.

        Existing implementations of authentication mechanisms will have to support both the proprietary identity stores as well as the new standardized ones. Additionally the JASPIC spec may have to be updated as well to support the new standardized identity stores (it currently only supports JAAS login modules).

        Variation 1 would already be a very good step in the right direction and should be relatively easy to specify and implement. Variation 2 is clearly much more work in all areas, but ultimately IMHO a better approach and one that makes both custom identity stores and custom authentication mechanisms a much more central and standardized artifact in Java EE.

        I think variation 1 does not prevent variation 2 to be realized at a later date, but as Java EE moves at a relatively slow pace a "later date" means a lot of extra time. E.g. suppose Java EE 8 happens in 2016/2017, then Java EE 9 may not happen before 2020/2021.

        Show
        arjan tijms added a comment - - edited Very, very much in favor of this! I see two possible variations of the requested functionality: 1. The proposed annotations map transparently to whatever proprietary identity stores the application server is already using. If a given AS doesn't already have a matching store it has to implement it of course. This will work very well with the build in authentication mechanisms (aka the messaging method, meaning how and via what way the authentication dialog with the user takes place), such as FORM, BASIC, DIGEST and CLIENT-CERT in Servlet, and most likely with the undefined concept of the EJB security domain as well. This will however not do anything for custom authentication mechanisms, e.g. those implemented via JASPIC. 2. The proposed annotations map to predefined implementations of the kind of module/provider that was proposed for JAVAEE_SPEC-9 and JAVAEE_SPEC-25 . These implementations can of course just wrap any existing proprietary identity store that already exist in a given AS. Existing implementations of authentication mechanisms will have to support both the proprietary identity stores as well as the new standardized ones. Additionally the JASPIC spec may have to be updated as well to support the new standardized identity stores (it currently only supports JAAS login modules). Variation 1 would already be a very good step in the right direction and should be relatively easy to specify and implement. Variation 2 is clearly much more work in all areas, but ultimately IMHO a better approach and one that makes both custom identity stores and custom authentication mechanisms a much more central and standardized artifact in Java EE. I think variation 1 does not prevent variation 2 to be realized at a later date, but as Java EE moves at a relatively slow pace a "later date" means a lot of extra time. E.g. suppose Java EE 8 happens in 2016/2017, then Java EE 9 may not happen before 2020/2021.
        Hide
        reza_rahman added a comment -

        Fully agree with everything Arjan stated. It's all a matter of priorities in the end, but all of this is very important, particularly with the emerging cloud paradigm.

        Please note that these are purely my personal views and certainly not of Oracle's as a company.

        Show
        reza_rahman added a comment - Fully agree with everything Arjan stated. It's all a matter of priorities in the end, but all of this is very important, particularly with the emerging cloud paradigm. Please note that these are purely my personal views and certainly not of Oracle's as a company.
        Hide
        dblevins added a comment - - edited

        Another solid proposal. It would be a breath of fresh air to see us handle the known use-cases with concrete APIs.

        I'm pretty tired of APIs that are so open ended and abstract they ultimately standardize nothing (JAAS), or so elaborate and intricate but pretend to be reusable they aren't even attractive for the use-case they were designed for (JACC).

        Even a simple spec requirement "you must support LDAP and Database as an identity store" would be a massive improvement.

        Show
        dblevins added a comment - - edited Another solid proposal. It would be a breath of fresh air to see us handle the known use-cases with concrete APIs. I'm pretty tired of APIs that are so open ended and abstract they ultimately standardize nothing (JAAS), or so elaborate and intricate but pretend to be reusable they aren't even attractive for the use-case they were designed for (JACC). Even a simple spec requirement "you must support LDAP and Database as an identity store" would be a massive improvement.
        Hide
        arjan tijms added a comment -

        I'm still a very big fan of this proposal. Reza had some very good ideas here As a side note, wondering why he didn't join the Security EG and/or discussions yet.

        Do note that this proposal somewhat depends on JAVAEE_SECURITY_SPEC-1 (if we want to standardize a few implementations of "something" it would be really great to have a name/term for that "something").

        It also depends on JAVAEE_SPEC-25 (the standardized things should very likely have the exact same interface/beantype/... that custom implementations provided by users have).

        Finally, JAVAEE_SPEC-37 sort of ties a couple of separate proposals including this one together.

        Show
        arjan tijms added a comment - I'm still a very big fan of this proposal. Reza had some very good ideas here As a side note, wondering why he didn't join the Security EG and/or discussions yet. Do note that this proposal somewhat depends on JAVAEE_SECURITY_SPEC-1 (if we want to standardize a few implementations of "something" it would be really great to have a name/term for that "something"). It also depends on JAVAEE_SPEC-25 (the standardized things should very likely have the exact same interface/beantype/... that custom implementations provided by users have). Finally, JAVAEE_SPEC-37 sort of ties a couple of separate proposals including this one together.
        Hide
        reza_rahman added a comment -

        Rest assured I am tracking all of these Java EE 8 discussions internally and externally with great interest. As an Oracle employee officially joining an expert group involves a lot more bureaucracy than when I was still simply an independent (I'd contend so much so that it is not worth the incremental effort at this juncture). That being said there is absolutely nothing stopping me from being an observer and voicing personal opinions where really needed.

        I think so far things look to be going in the right direction?

        Show
        reza_rahman added a comment - Rest assured I am tracking all of these Java EE 8 discussions internally and externally with great interest. As an Oracle employee officially joining an expert group involves a lot more bureaucracy than when I was still simply an independent (I'd contend so much so that it is not worth the incremental effort at this juncture). That being said there is absolutely nothing stopping me from being an observer and voicing personal opinions where really needed. I think so far things look to be going in the right direction?
        Hide
        arjan tijms added a comment -

        I think so far things look to be going in the right direction?

        For sure Still a lot of challenges to overcome, but I'm sure we'll get there.

        P.s. I've edited this issue and the comments to use the term "identity store" for what people here called "security provider" or "user store" etc.

        Show
        arjan tijms added a comment - I think so far things look to be going in the right direction? For sure Still a lot of challenges to overcome, but I'm sure we'll get there. P.s. I've edited this issue and the comments to use the term "identity store" for what people here called "security provider" or "user store" etc.

          People

          • Assignee:
            arjan tijms
            Reporter:
            reza_rahman
          • Votes:
            14 Vote for this issue
            Watchers:
            10 Start watching this issue

            Dates

            • Created:
              Updated: