SOAP administration wrappers

The SOAP administration wrapper  full-sdk  maps all commands defined in the OneSpan Authentication Server administration WSDL file in a class called AdministrationBean.

The administration commands return an AdministrationCommandResponse object that wraps the server’s response. For a list of different methods defined by this class, see Overview of SOAP wrappers.

Object model

To comply with the object-oriented aspect of the used programming language, the OneSpan Authentication Server Administration entity is wrapped by an object model. This object is essentially a container for the entities’ properties, since it has no logic.

These properties can be accessed using a specialized getter, e.g., getUserID(). To set these properties, use a specialized setter, e.g., setUserID(String userID).

For more information, see SOAP handler.

Query commands

The user, authenticator, reports, and pending operation handlers provide a search command (query). Query commands require a list of fields or business objects. These fields/objects will be used in the search. When successful, queries return a list of matching business objects with relevant fields set.

Search fields are interpreted as follows:

• Wildcards are always accepted, except for user and authenticator searches where the UserID or toSerialNumber parameters are used.

• A wildcard character (*) can be added to the values at the start, the end, or both. They will be interpreted as the SQL LIKE statement.

• A list of comma-separated values can be specified for the attribute that specifies the domain name. In this case it will be interpreted as the logical OR of the given values.

  You cannot use wildcard characters in comma-separated values.

• If none of the above applies, the search will be done using the exact match of the given value.

The search results are a list of respective objects (see Object model).

Session management

The object stores the session ID returned by OneSpan Authentication Server on login. Instances of that bean must be persistent through the user’s HTTP session. The persistence should be handled by the application server; implementing this is best practice, Java EE standard defines various mechanisms for this purpose.

There are two different methods for this implementation:

• You can encapsulate the AdministrationBean object in a stateful Enterprise Java Bean (EJB), which is supported by all major application servers. This permits the use of the bean in both servlets and JSP pages.

• Alternatively, you can use the <jsp:useBean> directive, with the scope attribute set to session. However, this solution is suitable only when integrated in JSP pages, since it does not grant access to the bean in a servlet. This method is used in the sample site.

Integrators can handle the persistence by storing the object in the Java EE session object. However, this is not recommended since it causes a lot of additional work. For more information and implementation details, refer to the Java EE specification.

Service users

When using a service user to execute administration commands, it is not necessary to perform an explicit login operation to acquire a session identifier (sessionID). Furthermore, it is not necessary to keep the session identifier persistent at all.

Instead, the service user’s credentials need to be put into the session identifier (sessionID) for each command. This can be achieved by creating an instance of AdministrationSessionStorage and configure it by calling createAndStoreSession() with the service user’s credentials as sessionID. This AdministrationSessionStorage instance can then be directly used to initialize the various handler helper classes.

 

AdministrationSessionStorage sessionStorage = new AdministrationSessionStorage();
sessionStorage.createAndStoreSession("Apikey serviceUserId:1234567890abcdef", "{soapURL}");
UserHandler userHandler = new UserHandler(sessionStorage);
userHandler.create(...);