This documentation is for WSO2 Application Server 5.2.0. View documentation for the latest release.
Dynamic User Authentication - Application Server 5.2.0 - WSO2 Documentation
||
Skip to end of metadata
Go to start of metadata

Dynamic user authentication allows to authenticate database users dynamically for each data service call. This functionality can be enabled and configured at the time a data source is created as follows.

Dynamic user authentication is implemented using a mapping between the Carbon users and the database users. This mapping can be static inside the data service configuration itself or, provided at runtime through a Java class which implements the interface "org.wso2.carbon.dataservices.core.auth.DynamicUserAuthenticator".

Static Configuration

Specified in the data source configuration section of the data service, as shown in the sample configuration snippet below.

<data name="RDBMSSample" serviceGroup="RDBMS">                           
   <config id="default">                                                      
      <property name="driverClassName">org.h2.Driver</property>                                      
      <property name="url">jdbc:h2:file:./samples/database/DATA_SERV_SAMP</property>
      <property name="username">wso2ds</property>
      <property name="password">wso2ds</property>
      <property name="dynamicUserAuthMapping">
         <configuration>
            <entry request="admin">
               <username>wso2ds</username>
               <password>wso2ds</password>
            </entry>
            <entry request="user1">
               <username>dbuser1</username>
               <password>dbpass1</password>
            </entry>
            <entry request="*">                                                                                  
               <username>guest</username>                                                                     
               <password>guest</password>                                                               
            </entry>                                                                        
         </configuration>                                                
      </property>                            
   </config>  
....

The configuration above maps the two Carbon users to specific database credentials and the rest of the users to a different username/password pair. The "dynamicUserAuthMapping" property at location "/configuration/entry/@request" represents the incoming Carbon user, and the "username" and "password" elements that follow represent the mapped database credentials.

For dynamic user authentication to work, security should be enabled in the data service throug UsernameToken for user authentication. If user authentication is not available when a "dynamicUserAuthMapping" section is specified, it will, by default map to the request="*" scenario.

The following figure shows a sample configuration of dynamic user mappings. For each entry, the Carbon user and the target database user/password can be mapped.

Runtime Configuration

In the runtime mode, the property "dynamicUserAuthClass" should be specified, instead of the data source configuration property "dynamicUserAuthMapping". The "dynamicUserAuthClass" property's value should have the fully-qualified class name of a Java class, which implements the interface "org.wso2.carbon.dataservices.core.auth.DynamicUserAuthenticator". The interface is as follows:

public interface DynamicUserAuthenticator {
     /**
     * This method is used to lookup a username/password pair given a source username.
     * @param user The source username
     * @return A two element String array containing the username and password respectively
     * @throws DataServiceFault
     */
     String[] lookupCredentials(String user) throws DataServiceFault;

}

The following sample configuration snippet shows an implementation of a dynamic user authenticator class.

package samples;
import org.wso2.carbon.dataservices.core.DataServiceFault;
import org.wso2.carbon.dataservices.core.auth.DynamicUserAuthenticator;

public class MyDynAuthClass implements DynamicUserAuthenticator {
     @Override
     public String[] lookupCredentials(String user) throws DataServiceFault {
             if ("admin".equals(user)) {
                 return new String[] {"wso2ds", "wso2ds"};
             } else if ("user1".equals(user)) {
                 return new String[] {"dbuser1", "dbpass1"};
             } else if ("user2".equals(user)) {
                 return new String[] {"dbuser2", "dbpass2"};
             } else {
                 throw new DataServiceFault("The user '" + user + "' not supported in invoking the target data service");
             }
      }
}

The "lookupCredentials" method takes in the request user and should return the database username/password in a String array. The dbs file configuration format is as follows:

<data name="RDBMSSample" serviceGroup="RDBMS">                           
   <config id="default">
      <property name="driverClassName">org.h2.Driver</property>
      <property name="url">jdbc:h2:file:./samples/database/DATA_SERV_SAMP</property>
      <property name="username">wso2ds</property>
      <property name="password">wso2ds</property>                                             
      <property name="dynamicUserAuthClass">samples.MyDynAuthClass</property>
....

The dynamic user authentication class can be specified in the field shown in the screenshot below.

Dynamic User Look-up Order of Precedence

In a single data source configuration, both the static and the runtime configurations can be available at once. In that case, they will be processed as follows:

  • Higher precedence goes to the static mapping in initially looking up the credentials. The "*" request setting will be ignored in the first pass.
  • If a request user/database credentials mapping cannot be found, the secondary runtime Java class implementation will be used to look up the user.
  • If the previous option also fails, the program will return for the primary static mapping and process the "*" request mapping.
  • The data service request will return an error only if all the above options fail.

Use of External Data Sources

When using non-inline data sources like Carbon, JNDI etc, the data sources must be specified in a way that its connections can be created for selected users. Specifically, in Carbon data sources, the setting "alternateUsernameAllowed" must be enabled for dynamic user authentication to function.

  • No labels