Creating and Assigning a Security Configuration That Uses X.509 Credentials

Create a new security configuration, assign the CertificateAuthenticationLoginModule authentication provider to it, and assign the security configuration to an Unwired Server domain or package.

1. Create the new security configuration:
   1. From Sybase Control Center, select Security.
   2. Select the General tab, click New, and enter a name for the new security configuration, for example, X509SECADMINCERT. Click OK.
2. Configure the new security configuration:
   1. Expand the Security folder.
   2. Select the X509SECADMINCERT security configuration.
   3. Select Authentication.
   4. Select New.
   5. Select com.sybase.security.core.CertificateAuthenticationLoginModule as the Authentication provider.
   6. Click OK to accept the default settings, or modify any of these settings as required:
      • Click <Add New Property>, select Validate Certificate Path and set the value to true.
      • If more than one truststore is defined in Unwired Server, click <Add New Property>, select Trusted Certificate Store and set the value to the location of the Java truststore that contains the Unwired Server trusted CA certificates. Otherwise, the default Unwired Server truststore is used.
      • If you change the default password for the truststore, click <Add New Property>, select Trusted Certificate Store Password and set the value of the truststore password.
   7. Click OK.
3. Select the General tab, select Validate, then Apply.
4. Assign the X509SECADMINCERT security configuration to an Unwired Server domain. This example uses the default domain, but you can specify any domain to which the package is deployed:
   1. Click Domains > DomainName > Security .
   2. Click Assign.
   3. Select X509SECADMINCERT and click OK.
5. If any other security configurations have been assigned to this SSO domain, Sybase suggests that you unassign them.
   However, many deployments of Unwired Platform do mix SSO and non-SSO MBOs or operations in the same package. There are certain operations that are not sensitive and do not require the overhead of setting up the SSO connection to the backend. Some packages may even perform DCNs, and the DCN user would not be part of the SSO-enabled login module. If you do authenticate a user against a non-SSO login module and then attempt to perform an SSO-enabled operation, then the credentials are sent to the backend, which may not be desired.