Update OIOIDWS endpoint to fully comply with OIO WS-Trust Profile v1.0.2

We have improved the OIOIDWS endpoint a bit to make sure it meets the OIO WS-Trust Profile v1.0.2 specification. All the “MUST” requirements are implemented, especially the Liberty binding is also supported.

Multiple user contexts

This documentation is not written to introduce about multiple user contexts but its usages for Identify*STS.

How does multiple user contexts work?

From 5.0, a user can have multiple contexts, and each context has an activation time and a certificate:

• An activation time is a period of time in which a user and the corresponding certificate is active.
• Every context must have a different certificate.

How is it used by Identify*STS

Prior to Safewhere*Identify 5.0, authentication process for a RST request against a local user is simply to verify whether the user is enabled or not. From 5.0, given that a user is set up with some user contexts, Identify will also check if the user has a user context which is valid at the time the RST is received. For certificate endpoint,  in addition to verify activation time, Identify will also match the user’s certificate in the RST to that of the activated user context.
Please note that existing users of an upgraded installation won’t have any user contexts and thus everything will just work as-is.

Configuration

In order to use this new feature, you need to do nothing but to create users with user contexts using REST API.

Multiple configurations and activation time for each connection’s configuration

This section focuses on the usages of multiple configurations and activation time for Identify*STS.

How does multiple configurations work?

Each connection has multiple configurations, and each configuration has an activation time. An activation time is a period of time in which the connection’s configuration is active.

How is it used by STS

Prior to Safewhere*Identify 5.0, when a RST comes, Identify*STS will look up a corresponding wstrust connection by comparing connection’s entityId with RST’s appliesTo. From now on, given that a connection has one or more configurations and they have activation time specified, Identify will compare configurations’ activation times against current time to find out a valid one in addition to the entityId check.
A newly created connection using Identify*Admin and existing connections of an upgraded tenants have only one configuration without activation time specified.

Configuration

In order to use this new feature, you need to do nothing but to create connections with activation times.

Claim definition’s activation time

In this section, we’re going to explore how claim definition’s activation time is used for Identify*STS.

How does the claim definition’s activation time work?

From 5.0, only claim definitions which have valid activation times are issued to requesters.

How is it used by STS

From 5.0, depends on different target, admin can allow or disallow issuing inactive claims Identify*STS will filter all the inactivated claims before putting them through claims pipeline to issue to client. In this case, an active claim is the claim having valid activation time on requested time.

Configuration

Please refer to this link for how to a scripting claims transformation to filter all inactive claims.