javaee-security-spec
  1. javaee-security-spec
  2. JAVAEE_SECURITY_SPEC-10

Simplify and standardize authentication & role mapping

    Details

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

      Description

      In Java EE declaring security constraints via e.g. @RolesAllowed, programmatically checking them via e.g. HttpServletRequest#isUserInRole and triggering a container login via HttpServletRequest#login is all relatively straightforward.

      Unfortunately, providing the logic for the actual authentication and role mapping/retrieval remains a cumbersome exercise. This is especially painful for simple applications which don't need elaborate security abstractions. JASPIC (JSR 196) did provide a means to make authentication modules portable in Java EE 6, but actually using those remains a fairly tedious and vendor specific process.

      For instance, JBoss AS 7 requires the following steps:

      1. Create a named security domain outside the application in a vendor specific way, that's tied to a specific AS instance.
      2. Connect the JASPIC authentication module to this security domain in a vendor specific way.
      3. Declare in web.xml that JASPI is the realm.
      4. Link the (web) application itself to the global security domain using a vendor specific descriptor.
      5. In the vendor specific descriptor, specify an internal vendor specific class name that's internally needed to activate JASPI.

      (See https://community.jboss.org/wiki/JBossAS7EnablingJASPIAuthenticationForWebApplications)

      GlassFish requires the user to take different, but similar steps including interacting with a graphical UI (see http://www-02.imixs.com/roller/ralphsjavablog/entry/openid_serverauthmodule_jsr_196_with)

      Not only are these steps anti ease-of-use, they are also notoriously non-portable despite JASPIC's promise of portability. Furthermore, having the authentication logic outside the application itself prohibits the developer to easily make use of application domain models and code for the authentication process (which is typical for applications that manage their users internally and don't need to integrate with an overall user directory system of e.g. an enterprise).

      I therefor would like to propose standardizing how JASPIC authentication modules can be embedded in (simple) applications in a portable way, and additionally address the use case that for small/test applications even a JASPIC module is too much and something even simpler is needed. This is especially true when the application already makes use of a custom mechanism (typically a Servlet Filter) in combination with HttpServletRequest#login.

      Example of simplified authentication/role mapping:

      @IdentityStore
      public class MyIdentityStore implements PasswordIdentityStore {
      
          private User user;
      
          @Inject
          private UserService userService;
      
          public void authenticate(String name, String password) {
              user = userService.getByNameAndPassword(name, password);
              if (user == null) {
                  throw new FailedLoginException();
              }
          }
      
          public String getUserName() {
              return user.getName();
          }
      
          public List<String> getApplicationRoles() {
              return user.getRoles();
          }
      }
      

      Following the presence of such simplified identity store in the application, the following should hold:

      • The application is considered to be in a default security realm.
      • The application will make use of this security realm (no explicit mention in web.xml required).
      • Whenever a container login is triggered, MyIdentityStore is used for authentication (only username/password supported of course)
      • If authentication succeeds, the String returned by getUserName will be what HttpServletRequest#getUserPrincipal.getName() and corresponding methods in EJB etc return.
      • For each String inside the list returned by getApplicationRoles, methods like HttpServletRequest#isUserInRole will return true, and annotations like @RolesAllowed referencing those will be considered satisfied.
      • No upfront declaration of roles in any descriptor is required.
      • The roles returned by getApplicationRoles should be directly useable in the application. Specifically, things as (vendor specific) group to role mappings (such as what happens in GlassFish) should not be required.

      Example of standardized installation of a JASPIC authentication module in application.xml or web.xml:

      <server-auth-module>
          <class-name>my.example.HTTPBasicServerAuthModule</class-name>
          <property>
              <name>usersProperties</name>
              <value>somepath/users.properties</value>
           </property>
      </server-auth-module>
      

      Alternatively, the presence of a JASPIC authentication module inside the application annotated with a special annotation (perhaps the same one as used for the simplified login module), can have the same effect of having the module automatically installed.

      Like the standardized identity store, when such a JASPIC authentication module is declared in an application, no further configuration, role mapping or role declarations should be required, other than those that are specific for the authentication module itself.

        Activity

        Hide
        arjan tijms added a comment -

        Thanks a lot for the thorough explanation. There are a lot of interesting ideas there.

        I do think it's especially important to establish some terminology and to take a look at how all individual ideas come together as a whole.

        Specifically there are two concepts that often come up and actually exist, but haven't got real clear distinguishing names:

        • The (user) interaction method via which credentials are obtained (form, basic, etc)
        • The store where users/callers and optionally the group/role data resides.

        The first item is what's more or less called "auth-method" in the Servlet spec, and "auth module" in the JASPIC spec. The second item is very indirectly called "realm" in the Servlet spec, but you'll often see the terms "repository" and "store" as well. JASPIC (optionally) delegates this functionality to a JAAS "LoginModule". JAVAEE_SPEC-28 calls these "security providers".

        The reason I'm bringing this up here is that if I understood correctly this second item corresponds to what you call a "UserSource" and a "UserService" (and in the running text refer to using "repository")

        A second issue, directly related to the above is that I'm wondering what the difference is between a UserSource and a UserService. In the example code they seem to be the same thing. There, a variable of type UserService is injected with a UserSource:

        @Resource(lookup=“java:app/prodUserSource”)
        private UserService userService;
        

        One thing I'm missing in the examples and API is a way to retrieve the groups/roles. This information is not in your UserInfo and the LdapUserSourceDefinition doesn't show any attribute used to hold the groups/roles query.

        In practice, there are often two queries defined for repositories. Eg for both SQL/DB and LDAP repositories you define one query to obtain just the user and another one to obtain the roles associated with a user. Some repositories, like a file based one, have their own internal format to store both users and their roles and no separate queries are needed. Yet other repositories, such as the increasingly popular OAuth based ones (Facebook, Twitter, ...) don't return roles at all (the app typically stores roles locally instead).

        As for the RoleMapper examples, here too I wonder what the difference is between the RoleMapper and RoleService; they seem to be the same thing as a RoleService variable is injected with a RoleMapper.

        I also wonder if LDAP can actually be used for (local) role mapping. It's sure used for role retrieval, but is it really used for local application role mapping? I don't think I've ever seen that.

        Finally, we may consider if the terms "group" and "role" are really needed. As you of course know, there's a third level of role mapping possible between the global application level roles and the roles of a single Java EE component (EJB bean or web module). There both source and target keeps using the term "role". I recognise that "group to role mapping" is an existing and reasonably well known term, but going forward with simplifying security it might be worth it to reconsider if those two terms are really needed.

        The problem I'm seeing is that in practice people dream up all kinds of fancy semantics related to the terms "group" and "role", thinking group is really like a group in normal English, while a role is more akin to a right, and what have you. Never ever have I seen anyone who intuitively understood that "group" is the "thing" returned by the auth module/login module and "role" is the "thing" after the mapping as required by some servers.

        With standardised role mapping one thing in favour of keeping the group / role terms though is that people could now start using it as the names intuitively imply; coarse grained / fine grained permissions.

        Well, just something to think about

        As for the authenticator example as given below:

        @Authenticator(userSourceName=“java:app/prodUserSource”,roleMapperName=“java:app/OneToOneRoleMapper” )
        

        I think there are a few things to remark here.

        Given the above mentioned distinction between the auth "method" and the "repository", I think the first one should be put here too. The method is after all not an alternative to the repository but a higher layer in a way; the method may decide not to call into a repository, but a repository always needs to be called by a method.

        A small cosmetic thing is that in JNDI it's a kind of de facto standard that "name" is an overloaded mess that both sets a name when a resource is defined and injects a name into the ENC (if any) when referenced. For referencing an existing name "lookup" seems to be more common.

        Another thing is that while for the example OneToOneRoleMapper is great, in practice I think this could better be the default for this kind of ease of use facility.

        Finally, I wonder if the API for this annotation would not be better off using CDI names and/or qualifyers instead of or in addition to JNDI.

        Anyway, keeping JNDI and the default role mapper it would then be something like this:

        @Authenticator(
        authMethodLookup="java:app/prodAuthMethod",
        userSourceLookup=“java:app/prodUserSource”,
        roleMapperLookup=“java:app/OneToOneRoleMapper” )
        

        In this example java:app/prodAuthMethod would refer to a configuration of a JASPIC module or one of the standard auth methods (like FORM). Bonus points for if there would not be a difference between those two and FORM was just a standardised JASPIC module.

        We now have the method which uses eg a form to get a username and password from the actual user, we have a userSource that retrieves the user (and presumably the roles) and we tell the server to use the roles directly.

        There's now just one thing missing (apart from the role retrieval mentioned above); what code is responsible for comparing the submitted password against the actual password? This has to be custom code too, as in general the server cannot assume any specific format or hash method/salt etc of the password (or any other type of credential).

        Show
        arjan tijms added a comment - Thanks a lot for the thorough explanation. There are a lot of interesting ideas there. I do think it's especially important to establish some terminology and to take a look at how all individual ideas come together as a whole. Specifically there are two concepts that often come up and actually exist, but haven't got real clear distinguishing names: The (user) interaction method via which credentials are obtained (form, basic, etc) The store where users/callers and optionally the group/role data resides. The first item is what's more or less called "auth-method" in the Servlet spec, and "auth module" in the JASPIC spec. The second item is very indirectly called "realm" in the Servlet spec, but you'll often see the terms "repository" and "store" as well. JASPIC (optionally) delegates this functionality to a JAAS "LoginModule". JAVAEE_SPEC-28 calls these "security providers". The reason I'm bringing this up here is that if I understood correctly this second item corresponds to what you call a "UserSource" and a "UserService" (and in the running text refer to using "repository") A second issue, directly related to the above is that I'm wondering what the difference is between a UserSource and a UserService. In the example code they seem to be the same thing. There, a variable of type UserService is injected with a UserSource: @Resource(lookup=“java:app/prodUserSource”) private UserService userService; One thing I'm missing in the examples and API is a way to retrieve the groups/roles. This information is not in your UserInfo and the LdapUserSourceDefinition doesn't show any attribute used to hold the groups/roles query. In practice, there are often two queries defined for repositories. Eg for both SQL/DB and LDAP repositories you define one query to obtain just the user and another one to obtain the roles associated with a user. Some repositories, like a file based one, have their own internal format to store both users and their roles and no separate queries are needed. Yet other repositories, such as the increasingly popular OAuth based ones (Facebook, Twitter, ...) don't return roles at all (the app typically stores roles locally instead). As for the RoleMapper examples, here too I wonder what the difference is between the RoleMapper and RoleService; they seem to be the same thing as a RoleService variable is injected with a RoleMapper. I also wonder if LDAP can actually be used for (local) role mapping. It's sure used for role retrieval, but is it really used for local application role mapping? I don't think I've ever seen that. Finally, we may consider if the terms "group" and "role" are really needed. As you of course know, there's a third level of role mapping possible between the global application level roles and the roles of a single Java EE component (EJB bean or web module). There both source and target keeps using the term "role". I recognise that "group to role mapping" is an existing and reasonably well known term, but going forward with simplifying security it might be worth it to reconsider if those two terms are really needed. The problem I'm seeing is that in practice people dream up all kinds of fancy semantics related to the terms "group" and "role", thinking group is really like a group in normal English, while a role is more akin to a right, and what have you. Never ever have I seen anyone who intuitively understood that "group" is the "thing" returned by the auth module/login module and "role" is the "thing" after the mapping as required by some servers. With standardised role mapping one thing in favour of keeping the group / role terms though is that people could now start using it as the names intuitively imply; coarse grained / fine grained permissions. Well, just something to think about As for the authenticator example as given below: @Authenticator(userSourceName=“java:app/prodUserSource”,roleMapperName=“java:app/OneToOneRoleMapper” ) I think there are a few things to remark here. Given the above mentioned distinction between the auth "method" and the "repository", I think the first one should be put here too. The method is after all not an alternative to the repository but a higher layer in a way; the method may decide not to call into a repository, but a repository always needs to be called by a method. A small cosmetic thing is that in JNDI it's a kind of de facto standard that "name" is an overloaded mess that both sets a name when a resource is defined and injects a name into the ENC (if any) when referenced. For referencing an existing name "lookup" seems to be more common. Another thing is that while for the example OneToOneRoleMapper is great, in practice I think this could better be the default for this kind of ease of use facility. Finally, I wonder if the API for this annotation would not be better off using CDI names and/or qualifyers instead of or in addition to JNDI. Anyway, keeping JNDI and the default role mapper it would then be something like this: @Authenticator( authMethodLookup= "java:app/prodAuthMethod" , userSourceLookup=“java:app/prodUserSource”, roleMapperLookup=“java:app/OneToOneRoleMapper” ) In this example java:app/prodAuthMethod would refer to a configuration of a JASPIC module or one of the standard auth methods (like FORM). Bonus points for if there would not be a difference between those two and FORM was just a standardised JASPIC module. We now have the method which uses eg a form to get a username and password from the actual user, we have a userSource that retrieves the user (and presumably the roles) and we tell the server to use the roles directly. There's now just one thing missing (apart from the role retrieval mentioned above); what code is responsible for comparing the submitted password against the actual password? This has to be custom code too, as in general the server cannot assume any specific format or hash method/salt etc of the password (or any other type of credential).
        Hide
        alex.kosowski added a comment -

        I'm wondering what the difference is between a UserSource and a UserService

        The UserSource would be an adapter between the repository and the UserService. We would standardize UserSource implementations for various repository types (LDAP, DataSource, etc). The UserService would provide user operations, delegating repository access to the UserSource. I suppose we could simplify and merge UserSource and UserService, perhaps standardize some service helper methods.

        One thing I'm missing in the examples and API is a way to retrieve the groups/roles.

        Sorry, missed that in the reply. Groups are just groups of users, with no authorization semantics without RoleService. To get groups from UserService:
        boolean isUserInGroup(String username, String group);
        List<String> getUserGroups(String username);

        Roles provide authority. To get role from RoleService:
        boolean hasRoleForUser(String username, String role, boolean includeGroups);
        List<String> getRolesForUser(String username, boolean includeGroups);
        List<String> getUsersWithRole(String role, boolean includeGroups);
        boolean hasRoleForGroup(String group, String role);
        List<String> getRolesForGroup(String group);
        List<String> getGroupsWithRole(String role);

        Note that the GroupIsRoleMapper would represent groups as roles.

        there are often two queries defined for repositories

        I would expect the standardized LDAPUserSource, DataSourceUserSource, etc, would be configurable for apps to declare queries for specific required operations.

        Yet other repositories, such as the increasingly popular OAuth based ones (Facebook, Twitter, ...) don't return roles at all (the app typically stores roles locally instead).

        UserService would be meant for applications to manage users. For OpenID Connect user repositories, I would expect a JASPIC SAM to cover that.

        I wonder what the difference is between the RoleMapper and RoleService

        Yup, perhaps we should simplify this terminology and just have RoleService implementations.

        I also wonder if LDAP can actually be used for (local) role mapping. It's sure used for role retrieval, but is it really used for local application role mapping? I don't think I've ever seen that.

        I was not sure if that was actually used, although I think it is possible. No need to standardize an uncommon use case.

        One idea we were considering was having role mapping be rule based. We could have the role mapping rules be based on EL, incorporating managed beans. We could store the rules inline or externally in file or LDAP. The rules would be evaluated before authorization decisions.

        I recognise that "group to role mapping" is an existing and reasonably well known term, but going forward with simplifying security it might be worth it to reconsider if those two terms are really needed.

        Group to role mapping arguably is needed for deployments where the enterprise is using applications developed by a third party. The mapping allows application authorization roles to be assigned from enterprise users. The one to one role mapper would provide a simplification for applications not requiring the mapping. I am not sure how to get away from role mapping and still accommodate the common Java EE security use cases.

        Another thing is that while for the example OneToOneRoleMapper is great, in practice I think this could better be the default for this kind of ease of use facility.

        Agreed

        I wonder if the API for this annotation would not be better off using CDI names and/or qualifyers instead of or in addition to JNDI.

        I think using JNDI is the current standard for referring to resources. Although CDI seems like the "hammer for everyone's nail", I could not find any standards for using CDI names to refer to resources.

        @Authenticator(
        authMethodLookup="java:app/prodAuthMethod",
        userSourceLookup=“java:app/prodUserSource”,
        roleMapperLookup=“java:app/OneToOneRoleMapper” )

        I agree with this. authMethodLookup would make sense if JASPIC were updated to be configurable with standardized SAMs. The absence of authMethodLookup infers the currently determined authmethod (e.g., via web.xml) would use the specified UserSource and RoleMapper for authentication within the application.

        what code is responsible for comparing the submitted password against the actual password? This has to be custom code too, as in general the server cannot assume any specific format or hash method/salt etc of the password (or any other type of credential).

        Since the UserService internally hashes/encrypts the password, I think the UserService should encapsulate that decision. For example, we could remove the Password attribute from UserInfo and add a UserService operation which would encapsulate the password check, like:
        boolean isValid( username, password )

        That said, we are also considering separating Password into a separate service: PasswordService or CredentialService. This would facilitate having a separate, more secure credential repository.

        Show
        alex.kosowski added a comment - I'm wondering what the difference is between a UserSource and a UserService The UserSource would be an adapter between the repository and the UserService. We would standardize UserSource implementations for various repository types (LDAP, DataSource, etc). The UserService would provide user operations, delegating repository access to the UserSource. I suppose we could simplify and merge UserSource and UserService, perhaps standardize some service helper methods. One thing I'm missing in the examples and API is a way to retrieve the groups/roles. Sorry, missed that in the reply. Groups are just groups of users, with no authorization semantics without RoleService. To get groups from UserService: boolean isUserInGroup(String username, String group); List<String> getUserGroups(String username); Roles provide authority. To get role from RoleService: boolean hasRoleForUser(String username, String role, boolean includeGroups); List<String> getRolesForUser(String username, boolean includeGroups); List<String> getUsersWithRole(String role, boolean includeGroups); boolean hasRoleForGroup(String group, String role); List<String> getRolesForGroup(String group); List<String> getGroupsWithRole(String role); Note that the GroupIsRoleMapper would represent groups as roles. there are often two queries defined for repositories I would expect the standardized LDAPUserSource, DataSourceUserSource, etc, would be configurable for apps to declare queries for specific required operations. Yet other repositories, such as the increasingly popular OAuth based ones (Facebook, Twitter, ...) don't return roles at all (the app typically stores roles locally instead). UserService would be meant for applications to manage users. For OpenID Connect user repositories, I would expect a JASPIC SAM to cover that. I wonder what the difference is between the RoleMapper and RoleService Yup, perhaps we should simplify this terminology and just have RoleService implementations. I also wonder if LDAP can actually be used for (local) role mapping. It's sure used for role retrieval, but is it really used for local application role mapping? I don't think I've ever seen that. I was not sure if that was actually used, although I think it is possible. No need to standardize an uncommon use case. One idea we were considering was having role mapping be rule based. We could have the role mapping rules be based on EL, incorporating managed beans. We could store the rules inline or externally in file or LDAP. The rules would be evaluated before authorization decisions. I recognise that "group to role mapping" is an existing and reasonably well known term, but going forward with simplifying security it might be worth it to reconsider if those two terms are really needed. Group to role mapping arguably is needed for deployments where the enterprise is using applications developed by a third party. The mapping allows application authorization roles to be assigned from enterprise users. The one to one role mapper would provide a simplification for applications not requiring the mapping. I am not sure how to get away from role mapping and still accommodate the common Java EE security use cases. Another thing is that while for the example OneToOneRoleMapper is great, in practice I think this could better be the default for this kind of ease of use facility. Agreed I wonder if the API for this annotation would not be better off using CDI names and/or qualifyers instead of or in addition to JNDI. I think using JNDI is the current standard for referring to resources. Although CDI seems like the "hammer for everyone's nail", I could not find any standards for using CDI names to refer to resources. @Authenticator( authMethodLookup="java:app/prodAuthMethod", userSourceLookup=“java:app/prodUserSource”, roleMapperLookup=“java:app/OneToOneRoleMapper” ) I agree with this. authMethodLookup would make sense if JASPIC were updated to be configurable with standardized SAMs. The absence of authMethodLookup infers the currently determined authmethod (e.g., via web.xml) would use the specified UserSource and RoleMapper for authentication within the application. what code is responsible for comparing the submitted password against the actual password? This has to be custom code too, as in general the server cannot assume any specific format or hash method/salt etc of the password (or any other type of credential). Since the UserService internally hashes/encrypts the password, I think the UserService should encapsulate that decision. For example, we could remove the Password attribute from UserInfo and add a UserService operation which would encapsulate the password check, like: boolean isValid( username, password ) That said, we are also considering separating Password into a separate service: PasswordService or CredentialService. This would facilitate having a separate, more secure credential repository.
        Hide
        arjan tijms added a comment -

        UserService would be meant for applications to manage users. For OpenID Connect user repositories, I would expect a JASPIC SAM to cover that.

        Hmmm, hopefully it will be possible to come to an abstraction where there will be no need for one group of authentication methods to have a different API/SPI.

        Group to role mapping arguably is needed for deployments where the enterprise is using applications developed by a third party.

        Yes, of course. But that wasn't what I meant Group to role mapping is a key requirement for the above use case and definitely shouldn't be done away with. What I meant is that the term group may not be necessary and could just be called role as well.

        E.g. we now have:

        Term Meaning
        Group Organization wide role
        Role Application wide role
        Role ref Component wide role

        The term group specifically is a source of confusion. People dream up all kinds of meanings for it, EXCEPT the meaning "organization wide role". I wasted so many hours trying to explain to different developers and in the end I think they still felt that group meant something else than it actually means.

        group is also not entirely consistently used. JASPIC recognizes the term and uses it in its API/SPI but JACC does not.

        Role ref is a problematic term too, but in practice not a big issue since it defaults to Role anyway and I think in practice people don't really use it (correct me if I'm wrong).

        Although longer, I feel calling the process something like "organization role to application role mapping" or somewhat shorter "organization to application role mapping" is quite a bit clearer. Alternatively, "global" could be used instead of "organization" as well, and "application" could be abbreviated leading to: "global to app role mapping". The new role hierarchy (wrt terminology) could then become:

        Term Meaning
        Global role Organization wide role
        Application Role Application wide role
        Component Role Component wide role

        I could not find any standards for using CDI names to refer to resources.

        CDI beans can be explicitly named (@Named annotation in user code, or the getName method in the Bean type for extensions).
        More common would however be the usage of bean types (i.e. Java interfaces) and/or qualifiers, which is a type safe approach.

        I think the UserService should encapsulate that decision.

        Should applications always subclass the UserService then, or do you envision a configurable choice of some well known standard hash/encrypt methods and a subclass or plug-in type if the algorithm the user uses is not among the standard choices?

        Show
        arjan tijms added a comment - UserService would be meant for applications to manage users. For OpenID Connect user repositories, I would expect a JASPIC SAM to cover that. Hmmm, hopefully it will be possible to come to an abstraction where there will be no need for one group of authentication methods to have a different API/SPI. Group to role mapping arguably is needed for deployments where the enterprise is using applications developed by a third party. Yes, of course. But that wasn't what I meant Group to role mapping is a key requirement for the above use case and definitely shouldn't be done away with. What I meant is that the term group may not be necessary and could just be called role as well. E.g. we now have: Term Meaning Group Organization wide role Role Application wide role Role ref Component wide role The term group specifically is a source of confusion. People dream up all kinds of meanings for it, EXCEPT the meaning "organization wide role". I wasted so many hours trying to explain to different developers and in the end I think they still felt that group meant something else than it actually means. group is also not entirely consistently used. JASPIC recognizes the term and uses it in its API/SPI but JACC does not. Role ref is a problematic term too, but in practice not a big issue since it defaults to Role anyway and I think in practice people don't really use it (correct me if I'm wrong). Although longer, I feel calling the process something like "organization role to application role mapping" or somewhat shorter "organization to application role mapping" is quite a bit clearer. Alternatively, "global" could be used instead of "organization" as well, and "application" could be abbreviated leading to: "global to app role mapping". The new role hierarchy (wrt terminology) could then become: Term Meaning Global role Organization wide role Application Role Application wide role Component Role Component wide role I could not find any standards for using CDI names to refer to resources. CDI beans can be explicitly named ( @Named annotation in user code, or the getName method in the Bean type for extensions). More common would however be the usage of bean types (i.e. Java interfaces) and/or qualifiers, which is a type safe approach. I think the UserService should encapsulate that decision. Should applications always subclass the UserService then, or do you envision a configurable choice of some well known standard hash/encrypt methods and a subclass or plug-in type if the algorithm the user uses is not among the standard choices?
        Hide
        yosshi2008 added a comment -

        In order to create the application with more strong user authentication,
        we would like to insert the password as SSHA(Salted SHA).
        And there was no way to implement it as standard.
        (It depends on the Application Server.)

        Thus could you also consider to implement the API which support the SSHA ?
        I assume that It may be influence following API.

        UserInfo properties:

        + Password
        
+ Attributes

        UserService operations:

        + UserInfo:loadUserByUsername(username)

        + changePassword

        + createUser

        + updateUser
        
+ addUserToGroup


        Show
        yosshi2008 added a comment - In order to create the application with more strong user authentication, we would like to insert the password as SSHA(Salted SHA). And there was no way to implement it as standard. (It depends on the Application Server.) Thus could you also consider to implement the API which support the SSHA ? I assume that It may be influence following API. UserInfo properties:
 + Password 
+ Attributes UserService operations:
 + UserInfo:loadUserByUsername(username)
 + changePassword
 + createUser
 + updateUser 
+ addUserToGroup

        Hide
        panga added a comment -

        I think it should be possible to build a custom principal even in the "simplified" JASPIC module.

        Show
        panga added a comment - I think it should be possible to build a custom principal even in the "simplified" JASPIC module.

          People

          • Assignee:
            alex.kosowski
            Reporter:
            arjan tijms
          • Votes:
            13 Vote for this issue
            Watchers:
            12 Start watching this issue

            Dates

            • Created:
              Updated: