Authentication

Authentication within CSI is performed internally using the Java Authentication and Authorization Services (JAAS) model by supplying the client credentials in an object instance that implements the javax.security.auth.callback.CallbackHandler interface.

SAP Mobile Platform caches a successful authentication result for a configurable time interval. If another authentication request using the same credentials is received within the authentication cache time interval after a successful authentication, the request is not delegated to CSI.

The authentication provider interfaces in CSI are primarily based on JAAS. The goal of the design is to allow any implementation of the JAAS pluggable authentication module system to alternatively plug into the CSI framework. Specifically, the javax.security.auth.spi.LoginModule interface must be implemented by all authentication providers. CSI provides a flexible mechanism for defining active authentication providers and their control flags. All control flags defined in JAAS are fully implemented in the SAP Mobile Platform architecture. See the JAAS documentation for a complete discussion of the configuration options available with JAAS login modules.

CSI instantiates new authentication provider instances, upon demand, for each authentication request. This is distinctly different from authorization and attribution providers, for which instances are reused and must be thread-safe. Normally, the first method called on a security context after creation results in authentication. The framework creates the authentication providers using the default public, no-argument constructor. If a provider class does not have a constructor meeting these requirements, a com.sybase.security.SecException object is created and thrown with the appropriate detail information.

The initialize() method call includes four arguments. The callback handler is how an authentication provider should attempt to retrieve credentials from the client. Also included is a javax.security.auth.Subject object, into which an authentication provider typically adds custom principals and credentials. The next argument is a java.util.Map instance that provides a way for all configured providers to share information. There are no standard way for providers to communicate with each other, but many of the providers that ship with the JDK support certain well-defined communication capabilities. The last argument is also a java.util.Map instance, which represents all of the provider-specific configuration options. Included in this argument are any URLs, user names, passwords, and anything else a provider needs to know about its environment to provide authentication services.

Principals play a crucial role in the JAAS and Java security models. It is through principals that a direct JAAS client can discover an authenticated user. A typical authentication provider might add one or more principals to the subject’s principal set (see the Subject.getPrincipals() method) after verifying the user’s identity. Each principal instance must include at least one method, getName(), which is defined in the java.security.Principal interface. The return value of this method is a unique string that represents this user in the underlying security system.

Principals themselves are not useful without any context about where they came from and what format they are in. After authentication is complete and the user’s principals are collected, CSI makes a pass through the set of principals and attempts to classify them according to some rudimentary rules. In particular, two categories are defined: name and ID. A principal that is the name of a user is thought to be a principal whose string representation presents itself in a relatively human-readable form. Something like the user name or e-mail address might be considered a name principal. A principal that is an ID principal is typically not very human-friendly–it might be a large number or a string of seemingly random characters that form a machine-readable unique identifier. 

Both of these principals are useful in their own places, so CSI provides a way to categorize a principal as a name and/or ID, or neither. You can use the empty interfaces com.sybase.security.providers.SecIDPrincipal and com.sybase.security.providers.SecNamePrincipal to tag custom authentication providers’ principals as name or ID, or both. If a principal instance implements the SecIDPrincipal interface, then the value returned from the getName() method is added to the security context as an ID attribute. Logically, principals that implement the SecNamePrincipal interface are added as NAME attributes in the security context. The actual principal instances themselves remain available to CSI clients and providers within the JAAS subject object, which you can retrieve using the SecSubject.getJAASSubject() method.

To facilitate role-based authentication, login modules may also retrieve the roles assigned to a user and add them as Principals to the authenticated subject. If these principals implement the interface com.sybase.security.core.RoleCheck, you can use the default authorizer com.sybase.security.core.RoleCheckAuthorizer, which is part of the SAP Mobile Platform configurations, to perform authorization checks without the need for an authorization provider for the specific back end.

• Credentials in Single Sign-on
  Created as a direct result of authentication, credentials are usually time-limited objects that you can use to perform tasks such as authorization checks, attribution requests, and single sign-on (SSO).