Details

    • Type: New Feature New Feature
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • 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 authentication/authorization/security providers 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 security providers that make some simplifying assumptions such as simple role mappings and only targeting the most common types of security providers. In fact, most application servers like Resin, JBoss and GlassFish already provide these sorts of simple security providers.

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

      @EmbedddedSecurityProvider(

      {@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 security provider 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.

      @DatabaseSecurityProvider(lookup="somedatabase", userQuery="SELECT password FROM principals WHERE username=?",
      rolesQuery="SELECT role FROM roles where username=?", ...)

      @LdapSecurityProvider(url="...", dnPrefix="...", dnSuffix="...", ...)

      These simple providers 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 -

        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 login modules/security providers the application server is already using. If a given AS doesn't already have a matching provider 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 login modules/security providers that already exist in a given AS.

        Existing implementations of authentication mechanisms will have to support both the proprietary module/providers as well as the new standardized ones. Additionally the JASPIC has to be updated as well to support the new standardized security providers (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 security providers 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 - 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 login modules/security providers the application server is already using. If a given AS doesn't already have a matching provider 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 login modules/security providers that already exist in a given AS. Existing implementations of authentication mechanisms will have to support both the proprietary module/providers as well as the new standardized ones. Additionally the JASPIC has to be updated as well to support the new standardized security providers (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 security providers 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.

          People

          • Assignee:
            ldemichiel
            Reporter:
            reza_rahman
          • Votes:
            12 Vote for this issue
            Watchers:
            7 Start watching this issue

            Dates

            • Created:
              Updated: