The checkRole() method accepts three arguments: the context map, the role name, and a SecSubject object.
The first argument is the context map. This is the same argument that was passed into the initContext() method, so any information saved in that method call is now available using this object instance.
The second argument provided to the checkRole() method is the role name. The specifics of how the implementation interprets this string argument are determined during implementation. However, SAP strongly recommends that authorization and attribution providers coordinate their efforts. This ensures the results from an attribution provider’s listRoles() method return named objects whose identifiers are supported as role name arguments in the authorization provider’s checkRole() method. It is possible for the provider’s checkRole() implementation to accept multiple role-name formats beyond those returned by the attribution provider.
The third argument provided to the checkRole() method is a SecSubject object. Note that this is not necessarily the subject object that is authenticated into the active security context, which can be retrieved from the first argument (context map). In CSI, it is possible for a security client to perform a role check on another security subject. Not all providers need support this capability – if the provider does not, then it should simply return ProviderConst.ABSTAIN.
There are three valid return values from an authorization provider authorization check (both role and access check), all of which are contained in the com.sybase.security.ProviderConst interface. YES, NO, and ABSTAIN are the three constants. In general, if a provider can verify the existence of a role and can verify that the specified SecSubject does not have the role, the provider should return NO. Otherwise, the provider should return ABSTAIN.
For example, the RoleCheckAuthorizer provider provides role checking capabilities when the login module adds principals and credentials that implement the RoleCheck interface. This provider checks if a principal or credential exists in the JAAS subject with the specified role name and that it implements the RoleCheck interface. If the provider finds one, it returns YES. Note that the absence of a principal or credential does not guarantee that the role is not granted to the authenticated user, because the user might be granted the role through an alternate provider in a mixed security model. In this case, the provider must return ABSTAIN or lose interoperability with other authorization providers.