Credential Manager and Token-based Authentication

Traditionally, U2 applications need to provide OS-based user credentials (namely, OS user account names and passwords) to establish a connection to U2 database servers, which then perform authentication based on the credential and set the identity of the U2 processes accordingly. With the proliferation of the Cloud, more and more users are moving their applications into the cloud where OS-based authentication schemes are increasingly getting harder to maintain and use. Some U2-based application vendors are beginning to adopt third-party Identity Management (IdM) products for their in-cloud applications. With such an approach, the end users are no longer issued or asked to provide OS-based credentials for logging into the applications. Instead, they authenticate to the third-party IdM where an access token is returned to the application after a successful validation. The application consumes the token and provides services according to the granted rights embodied in the token.

One problem arises in this picture: The underlying U2 servers are not capable of consuming the IdM tokens directly. U2 servers still need to have OS-based user credentials to function. Now, most likely, the third-party IdM token won’t have any OS-based password stored therein, and sometimes may not even have an OS-based user account name associated with it. Put another way, the old-world application uses the same OS-based credentials for both front-end and back-end to establish trust. The new-world application may have an IdM-based way to establish trust for the front-end. But what about the backend? To transfer the trust established from the interaction between the user and IdM to the user and U2 servers, there must be a medium for the applications to tell the U2 servers that, “Hey, this user has been authenticated and is OK to be trusted, although we don’t have his/her password, or worse, we don’t even have his/her user name on your system, but please run as some predefined group identity”.

That’s exactly what the U2 Credential Manager is designed to accomplish.

Credential Manager allows a system administrator to predefine a mapping between application credentials to OS-based credentials, thus transferring the in-cloud trust into U2’s OS-based trust, melting together the advancement of the third-party IdM used by cloud applications and the existing U2 authentication model. Sometimes we refer to this as “mapping between logical identities and physical identities”. We use an “Authentication Token” (hereafter referred to simply as a Token) to represent such a mapping, and describe an application using these types of Tokens as “using Token-based authentication”.

Credential Manager stores the Tokens in its credential wallet – a simple, secure and highly efficient identity storage. When an application makes a connection request to a U2 server, instead of providing the traditional OS credential, now it can provide the Token credential. U2 servers are capable of consuming both forms of credentials and authenticate users accordingly. If an application chooses to use Token-based authentication, it authenticates itself (on behalf of the end user) to a U2 server using the Token credential. Once this is done successfully, the U2 server then runs under the mapped OS identity, without the need for an OS password.

Now, let’s examine the Token structure in more detail.

Currently, a Token has the following properties:

If an application needs to use Token-based authentication, the TokenID and TokenPass must be provided when connecting to a U2 server. Currently, the TokenType is used only internally by U2. The DflOSID is a valid OS user account name that will be used if an application does not provide an actual OS account name during connection establishment. The Services field specifies which U2 services are allowed to consume this particular Token. Currently only four values are permitted: UDCS and UVCS for InterCall type of services (such as UO, UOJ or .NET), and UDSERVER and UVSERVER for UCI/ODBC type of services. By using this field, you can further restrict the availability of Token-based authentication. The Members field can contain a list of OS user names and group names, which will be used to verify if a given user name is on the list. If a user name is found on the list this means the mapping is considered successful, otherwise it is declined. The Domains field is only meaningful on Windows. If it is specified, you don’t need to provide it as a part of the credential each time you authenticate to U2 servers.

With Token-based authentication enabled U2 servers, a client application can authenticate to a U2 server using the following three forms of credentials:

  1. Old-style OS credential:

    A U2 server will handle this type of credential as before, using the direct OS authentication mechanism. Once authenticated, the U2 server will run under the authenticated OS user.
  2. Token-based, with OS account name:

    A U2 server will consult the Credential Manager to validate the mapping. Once the Token credential is validated, the U2 server will run under the supplied OS user. Note that no OS password is needed here.
  3. Token-based, without OS account name:

A U2 server will consult the Credential Manager for a valid mapping. Once the Token credential is validated, the U2 server will run under the OS user defined in the DflOSID field of the Token.

Let’s examine a few examples so that you have a better understanding of how the Token-based authentication is performed in some hypothetical scenarios.

Example 1: Map to a specific OS user

Suppose we have a Token “SALES” created as follows:

If a client application supplies “bobk@SALES SalesPass” to a U2 server, the mapping will succeed because the provided Token credential is valid, and “bobk” is among the Members specified. U2 server runs under bobk.

If a client application instead supplies “tomw@SALES SalesPass” to a U2 server, the mapping will fail since user “tomw” is not in the Members list.

Example 2: Map to the default OS user

Suppose we have the same SALES token:

But a client presents “@SALES SalesPass” to a U2 server. The mapping will succeed because the Token credential matches. The U2 server will run under OS user “sales” since the client did not specify a specific user in the login credential. This type of mapping can be used in a scenario where the middle-layer already authenticated a user and determined his group membership, and allows the backend to run under a “group” ID. Similarly, you can define Tokens for different groups or departments, such as LABS, HR or ACCOUNTING, etc.

Example 3: Map to different systems

Suppose we defined SALES Token on a Windows system:

And SALES Token on an AIX system:

A ‘*’ in front of an ID is a group indicator.

A client running on Windows presenting “@SALES SalesPass” will be successfully authenticated, and the backend U2 server will run under “DOM1\SALES”.

A client running on AIX presenting “@SALES SalesPass” will be successfully authenticated, and the backend U2 server will run under “sales”.

This is how you can implement your middle tier applications to be agnostic to backend OS specifics.

Example 4: Guest access to system

You can define a Token to give a user temporary access to your system:

From time to time, you may need to grant temporary guest access to your system. For example, a developer may need to debug on a live system, or a partner may need to access your data in an emergency. The guest can access your system by providing “@Guest AGuestPass” to login. Once the scheduled access or service is done, you can change the Token password, effectively revoking the access granted to the guest. The access grant and revoke are all done at the DBMS level. You don’t need to ask your OS admin to create a new account or change a password. Sometimes this approach is considered more convenient and more secure.

Before closing I must mention one caveat: For the described behavior to work on a Windows system, the user must either be defined on the primary domain controller, or you must establish a mutual trust between your user domain and the domain your U2 servers are running on. This means users defined local only to the U2 server will not work. Without this mutual trust, the no-OS-password authentication mechanism won’t work on Windows. This is a restriction strictly from Microsoft.

In summary, Credential Manager provides a light-weight, flexible and convenient mapping between your new, in-cloud, logical identities and your current, backend, physical identities. Rocket also provides a full-featured XAdmin interface, as well as command line tools for you to manage the Credential Manager and all the mappings you need for your applications. Rocket provides detailed technical documentation to help you with the usage of this feature. If you have any questions please contact Rocket Technical Support, or browse the Rocket U2 documentation website for more technical details.

Jing Cui

Jing Cui 5 Posts

I have been a member of the Rocket MV product development team for over 25 years. Most recently my focus has been on enhancing the database server's security offerings, including SSL, data encryption and audit logging. I have been closely following the ever-changing security landscape of the industry and am committed to bringing new security features into our Rocket MV product families.


  • Lee Roller Reply

    September 9, 2018 at 7:51 am

    So how does a shared token facilitate audit logging? If tokens are shared across a group or an entire enterprise how can audit transaction be traced back to an individual. Auditors are pretty attached to the idea of knowing which individual performed which transaction?

    And if you went as far as creating a token for each user, is there a practical limit on that? If you have say, 3000 users who actively connect to the UV system would this even support that?

    And do the tokens support expiry and self service update? If UV is a PCI system in your enterprise those credentials will need to have an enforced shelf-life. Does it support that? Can the users update their own token upon expiration (assuming expiry is even possible) or does that have to be done by an administrator?

    • Jing Cui Reply

      September 13, 2018 at 10:45 am

      Hi Lee:

      These are excellent questions.

      First of all, the granularity for Audit Logging is depended on how the log-in was done. If the first mapping format was used (OS-user@Token), then the UV process would run under that OS user in which case the auditor requirement would be met. However, if the second format was used (@Token so mapping to default OS user) then the UV process would run under that mapped user. If nothing else is done you would lose the audit logging granularity, because that information was never given in the whole authentication process. To resolve this problem some application level changes would be required, such as after establishing the connection the client side should call a server side routine to provide additional user-identifying info and the AuditLog() function can be used to put this info into system audit log files.

      The Credential Manager was designed to handle large number of mappings. However, understandably, the management of which is going to become problem as the number of tokens grow. Currently there is no password expiry for the tokens and the tokens can only be crated/changed by an administrator. Fundamentally the UV processes are still run under a valid OS user account so the password policy on that account will govern.

      If business needs require such a password policy on tokens, please raise the requirement with Rocket Tech Support.

Leave a Comment

Your email address will not be published. Required fields are marked *