Multiple Provider Interaction

When multiple active providers are configured, CSI reconciles conflicting decisions across the providers.

Security configurations can include a variety of active providers, all interacting and voicing their own perspective on an incoming request. CSI reconciles the conflicting decisions.

Authentication is unique in that it is partly the responsibility of the individual providers and partly the responsibility of the CSI configuration. CSI uses the JAAS authentication model for authentication and allows each provider to be associated with a control flag (required, requisite, sufficient, and optional). See http://www.oracle.com/technetwork/java/javase/jaas/index.html for an introduction to the JAAS model. When reviewing the JAAS model, consider references to LoginContext the same as SecContext because CSI provides its own entry point.

An additional feature the framework adds on top of the JAAS model is the ability to detect impersonation. This is meaningful when both a user name and other data (certificate or an opaque token) are provided in an authentication request. When the authentication succeeds, the authenticated subject’s attributes contain the Const.ATT_NAME attribute with the value set to the set of names (derived from the Principal objects of type com.sybase.security.provider.SecNamePrincipal) aggregated from the configured providers.

If the configured providers only consider the extra data (for example, certificate or token) and add Principal objects based on that, the supplied user name may not match any of the values for the Const.ATT_NAME attribute of the authenticated subject. When it is critical for the supplied user name to match at least one of the Principal names, you can set the configuration property checkImpersonation to true. This results in authentication failure even when all the configured login modules succeed but none of the Named principal names match the supplied user name.

in CSI, the result of authorization operations is either YES, NO, or ABSTAIN. However, there may be multiple authorization providers all vying to respond to a given authorization request. Providers have three possible answers to the authorization question – true, false, or abstain. Abstain should be used when a provider is not capable of answering yes or no. CSI denies the authorization request if either of the following occurs:

Any authorization provider returns NO
No authorization provider returns YES

CSI permits the authorization request in any other situation. Another way of describing a successful authorization request is when at least one authorization provider returns YES and none return NO.

The result of attribution operations is also a combined exercise. For methods such as enumeration methods, the union of the corresponding values for each provider is created and returned to the client. For attributed objects, the union of the attributes that each provider states are created.

For example, Provider A knows that Resource A has a NAME attribute of "Resource A" and an OWNER attribute of "Bob". Provider B knows that resource A has a NAME attribute of "Resource A-B" and a GROUP attribute of "Sales". The net attribute names and values for Resource A would be NAME = {"Resource A", "Resource A-B"}, OWNER="Bob", GROUP="Sales".