Chapter 6. Managing User Accounts

Procedure 6.1. Add a New User

1. Open the soa-users.properties file in a text editor: vi SOA_ROOT/jboss-as/server/PROFILE/conf/props/soa-users.properties. Add the user's name and password on a new line, using this syntax: username=password.
   Here is an example for a user with the login name "Harold":

   harold=@dm1nU53r
   

   Note

   Any line in this file that begins with a hash (#) is ignored. (You can use this convention to temporarily disable a user account.)
2. Save the changes to the file and exit the text editor.
3. Open the soa-roles.properties file in a text editor: vi SOA_ROOT/jboss-as/server/PROFILE/conf/props/soa-roles.properties. Add the user and the roles you wish to assign to them on a new line, using this syntax: username=role1,role2,role3.

   harold=JBossAdmin,HttpInvoker,user,admin
   

   Note

   You can assign any number of roles. Note that a user must be assigned the JBossAdmin, HttpInvoker, user and admin roles in order to be able to log into the server consoles.

   Any line in this file that begins with a hash (#) is ignored. You can use this convention to temporarily disable user roles.
4. Save the changes to the file and exit the text editor.

Procedure 6.2. Disable a User's Account

1. Open the soa-users.properties file in a text editor: vi SOA_ROOT/jboss-as/server/PROFILE/conf/props/soa-users.properties. Either delete the entire line containing the user's name and password or simply put a hash (#) in front of it to "comment it out."
   Here is an example for a user with the login name "Harold":

   #harold=@dm1nU53r
   

2. Save the changes to the file and exit the text editor.

Procedure 6.3. Task

1. Obtain the Login Module (LM) located in org.picketlink.identity.federation.core.wstrust.auth.STSIssuingLoginModule
2. Open the LM's configuration file.
3. Enter the following code, inserting the names of the services you wish to use:

   <application-policy name="saml-issue-token">
        <authentication>
            <login-module code="org.picketlink.identity.federation.core.wstrust.auth.STSIssuingLoginModule" flag="required">
                <module-option name="configFile">picketlink-sts-client.properties</module-option>
                <module-option name="endpointURI">http://security_saml/goodbyeworld</module-option>
            </login-module>
            <login-module code="org.picketlink.identity.federation.core.wstrust.auth.STSValidatingLoginModule" flag="required">
                <module-option name="configFile">picketlink-sts-client.properties</module-option>
            </login-module>
        </authentication>
    </application-policy>
   

   This configuration uses a stacked LM. The security token from the first LM is later used by the second LM which will validate the security token. Having two separate LMs for this can be useful as there can be situations where you only need to validate a security token.
4. Specify the picketlink-sts-client properties:

   serviceName=PicketLinkSTS
   portName=PicketLinkSTSPort
   endpointAddress=http://localhost:8080/picketlink-sts/PicketLinkSTS
   username=admin
   password=admin
   

   Note

   The username and password in this file are only used by the STSValidatingLoginModule. The username and password may also be stacked or provided by a callback.
5. To use this LM in JBossESB you need to update your server's login-config.xml with the above application-policy. You must also point the ESB service to where you want this LM to be used.
   For example, this is how you could configure it in jboss-esb.xml:

   <service category="SamlSecurityQuickstart" name="issueTokenService" invmScope="GLOBAL"
       description="This service demonstrates how a service can be configured to issue and validate a security token">
   
    
   
       <security moduleName="saml-issue-token" callbackHandler="org.jboss.soa.esb.services.security.auth.login.JBossSTSIssueCallbackHandler">
           <!-- disable the security context timeout so that our security context is re-evaluated -->
           <property name="org.jboss.soa.esb.services.security.contextTimeout" value="0"/>
       </security>
       ...
   </service>
   

   The callbackHandler that is is specified is specific to the ESB. This is because it requires access to the authentication request in the ESB for retreiving the username and password of the user for whom a security token should be issued.

Procedure 6.4. Task

1. Open the Login Module (LM) from org.picketlink.identity.federation.core.wstrust.auth.STSIssuingLoginModule.
2. Configure the properties file as shown in the example below:

           <application-policy name="saml-validate-token">
       <authentication>
           <login-module code="org.picketlink.identity.federation.core.wstrust.auth.STSValidatingLoginModule" flag="required">
               <module-option name="configFile">picketlink-sts-client.properties</module-option>
           </login-module>
       </authentication>
   </application-policy>
   
    
   
   And in jboss-esb.xml:
   <service category="SamlSecurityQuickstart" name="securedSamlService" invmScope="GLOBAL"
       description="This service demonstrates that an ESB service can be configured to only validate a security token.">
   
       <security moduleName="saml-validate-token" callbackHandler="org.jboss.soa.esb.services.security.auth.login.JBossSTSTokenCallbackHandler">
           <!-- disable the security context timeout so that our security context is re-evaluated -->
           <property name="org.jboss.soa.esb.services.security.contextTimeout" value="0"/>
       </security>
       ...
   </service>
   

   Note

   The callbackHandler that is specified is specific to the ESB. This is because it requires access to the authentication request in the ESB for retreiving the SAML Token which is to be validated.

   Note

   An example of SAML support in JBossESB can be found in the security_saml quickstart. More information about the Login Modules provied by PicketLink can be found at http://www.jboss.org/community/wiki/STSLoginModules