9 Replies Latest reply on Sep 23, 2008 8:31 AM by Anil Saldanha

    UsernameToken authentication and authorization for POJO endp

    Darran Lofthouse Master

      I am thinking about having a look at this issue and just wanted to bring up some ideas here. The reason I am looking at this is because although there is a solution based on using EJB endpoints there is still a consistent demand for this capability for POJO endpoints.

      We currently have the following unscheduled issue: -

      http://jira.jboss.org/jira/browse/JBWS-1999

      I have seen the contributed code but this does not integrate with our current WS-Security handlers so I am proposing a more integrated solution.

      My idea would be to re-open the following issue to allow the UsernameToken to be set as a requirement on the incoming message: -

      http://jira.jboss.org/jira/browse/JBWS-1136

      The configuration should have an attribute 'authenicate=true', if set we can make use of the programatic web authentication available from JBoss 4.2.0.GA: -

      http://wiki.jboss.org/wiki/WebAuthentication

      In addition to this the configuration could then contain a set of the allowed roles to call the endpoint and if this is set after the authentication we could use isCallerInRole to verify if the user is in the allowed role.

      The use of the WebAuthentication above does mean that we can mainly use the standard servlet APIs after the authentication and this change would be achieved with a small amount of additional configuration, as we have authenticated then this will still be propagated to the calls to any subsequent EJBs.

      I will need to consider the implications of this if a user enables it for an EJB endpoint as it does depend on the web app having a security domain but the primary purpose of this change is for POJO endpoints and not EJB endpoints.

        • 1. Re: UsernameToken authentication and authorization for POJO
          Alessio Soldano Master

           

          "darran.lofthouse@jboss.com" wrote:
          I am thinking about having a look at this issue and just wanted to bring up some ideas here. The reason I am looking at this is because although there is a solution based on using EJB endpoints there is still a consistent demand for this capability for POJO endpoints.

          We currently have the following unscheduled issue: -

          http://jira.jboss.org/jira/browse/JBWS-1999

          Hi Darran, interesting there's a consistent demand for these ws-security related features. That issue is assigned to me but you're welcome to reassing and work at it.

          I have seen the contributed code but this does not integrate with our current WS-Security handlers so I am proposing a more integrated solution.

          I think the idea of forcing the authentication calling the WSSecurityManager's .authenticate(...) method is good, that's imho the missing piece for pojo endpoints, since with ejb3 endpoints the ejb3 layer takes care of requesting the authentication.
          Of course I agree with you we can't have this called from other handlers; I didn't spend a lot of time looking at this, but I guess the current ReceiveUsernameOperation could be a nice place to do this.

          My idea would be to re-open the following issue to allow the UsernameToken to be set as a requirement on the incoming message: -

          http://jira.jboss.org/jira/browse/JBWS-1136

          Generally speaking, I agree with you the should be a way to say "ok, the username token is required".


          The configuration should have an attribute 'authenicate=true', if set we can make use of the programatic web authentication available from JBoss 4.2.0.GA: -

          http://wiki.jboss.org/wiki/WebAuthentication

          In addition to this the configuration could then contain a set of the allowed roles to call the endpoint and if this is set after the authentication we could use isCallerInRole to verify if the user is in the allowed role.

          The use of the WebAuthentication above does mean that we can mainly use the standard servlet APIs after the authentication and this change would be achieved with a small amount of additional configuration, as we have authenticated then this will still be propagated to the calls to any subsequent EJBs.


          I think it would be better to leave the configuration of the allowed roles to the login module configuration. May be I'm missing something, but I think we could simply let the user configure the security domain as usual and then the login module(s) configured for that security domain will have the roles configuration. Btw doing this you'll also get the digest/nonce feature of the UsernameToken Profile for free (see the test for JBWS-1988) also for pojo endpoints.

          • 2. Re: UsernameToken authentication and authorization for POJO
            Anil Saldanha Master

            Why not just design a generic solution around invoking the JBoss Security Managers by doing a JNDI lookup (works both in web and ejb2 containers)

             // Get the JBoss security manager from the ENC context
             InitialContext iniCtx = new InitialContext();
             SecurityManager securityMgr = (SecurityManager) iniCtx.lookup("java:comp/env/security/securityMgr");
             SimplePrincipal principal = new SimplePrincipal(username);
             if( securityMgr.isValid(principal, password) )
             {
            


            Darran, may I humbly request you to finish my beta release before you assign this JBossWS feature request?

            • 3. Re: UsernameToken authentication and authorization for POJO
              Darran Lofthouse Master

               

              "alessio.soldano@jboss.com" wrote:

              I think it would be better to leave the configuration of the allowed roles to the login module configuration. May be I'm missing something, but I think we could simply let the user configure the security domain as usual and then the login module(s) configured for that security domain will have the roles configuration.


              The reason that we need the additional role check is because the login modules do not actually verify the roles that the user is a member of, the login modules just load the list of roles. The list of roles is then checked against the required roles in the servlet container or in the EJB container.

              "anil.saldhana@jboss.com" wrote:

              Why not just design a generic solution around invoking the JBoss Security Managers by doing a JNDI lookup (works both in web and ejb2 containers)


              If the code you show is the better way to do it then there is no problem doing it that way as well, however we do not have a need for the actual code to be portable across the containers as the WS-Security handlers are always called within a web application. Even if you deploy an EJB endpoint a web application is automatically deployed to handle the actual WS requests.




              • 4. Re: UsernameToken authentication and authorization for POJO
                Anil Saldanha Master

                Something along the lines of:

                
                Object obj = ctx.lookup("java:comp/env/security/securityMgr");
                AuthenticationManager am = (AM)obj;
                am.isValid(Principal,Object);
                
                //Do generic authz
                RealmMapping rm = (RM)obj;
                rm.doesUserHaveRole(.....)
                


                should work.

                • 5. Re: UsernameToken authentication and authorization for POJO
                  Darran Lofthouse Master

                  Just an additional note regarding the faults returned on authentication failure, according to the WS-Security specification it is recommended that for an authentication failure the faultcode is 'wsse:FailedAuthentication' and the faultstring is 'The security token could not be authenticated or
                  authorized'.

                  • 6. WS-Security authentication and authorization for POJO endp
                    Darran Lofthouse Master

                    I need to make some changed to the design as the fixes for JBWS-1907 and JBWS-652 have made some changes to the schema so the configuration for this task needs to be reviewed to make sure it compliments the previous changes.

                    The changes for those two Jira issues added a new 'authenticate' element to the WS-Security configuration to allow a user to define which incoming token should be used for authentication.

                    For the Jira issue I am working on I would like to add a new element 'authorize' under the 'requires' element, this will be used to indicate that authorization is required, as authentication is a pre-requisite of authorization this will also be the trigger to switch on authentication.

                    A new operation 'AuthorizeOperation' will be added to JBossWS and this will be called last if the 'authorize' element is present. The purpose of this operation will be to take whatever is set on the 'SecurityAssociation' and perform the authentication and authorization using the approach shown by Anil.

                    The configuration would look as follows: -

                    <config>
                     <requires>
                     <authorize>
                     </unchecked>
                     </authorize>
                     </requires>
                    </config>
                    


                    This first example has an 'unchecked' element, this means no roles will be checked but authentication must succeed.

                    <config>
                     <requires>
                     <authorize>
                     <requiredRoles>
                     <role>friend</role>
                     <role>family</role>
                     </requiredRoles>
                     </authorize>
                     </requires>
                    </config>
                    


                    In this configuration the authentication will proceed and then the principal will be checked for membership in the friend or family roles.



                    • 7. Re: WS-Security authentication and authorization for POJO en
                      Alessio Soldano Master

                       

                      "darran.lofthouse@jboss.com" wrote:
                      A new operation 'AuthorizeOperation' will be added to JBossWS and this will be called last if the 'authorize' element is present. The purpose of this operation will be to take whatever is set on the 'SecurityAssociation' and perform the authentication and authorization using the approach shown by Anil.

                      The configuration would look as follows: -

                      <config>
                       <requires>
                       <authorize>
                       </unchecked>
                       </authorize>
                       </requires>
                      </config>
                      



                      OK Darran, that's fine with me. Is this going to apply to both pojo and ejb endpoints, isn't it?

                      • 8. Re: UsernameToken authentication and authorization for POJO
                        Darran Lofthouse Master

                        Really this should just be for POJO endpoints, EJB3 endpoint already have a mechanism available to them.

                        We can make it available for EJB3 endpoint, the only problem is that as part of the deployment process the jboss-web.xml for the generated web app would need the same security domain as the EJB.

                        Using this for EJB3 endpoint could give the ability to restrict who can use the WS endpoint without affecting who can call the bean i.e. maybe only family can call the WS but friends or family can call the EJB3 method directly.

                        • 9. Re: UsernameToken authentication and authorization for POJO
                          Anil Saldanha Master

                          Security Domain is very critical. Apart from the jboss-web.xml of the generated web-app having the same SD as the ejb3, there is a possibility of the web app inheriting the ear level SD if they are packaged in an ear. But we cannot rely on EARs being the deployment for the ejb3 based web services. fyi.