Configuration Settings for Get Assumable Roles
The following section provides administrators with information on how to configure the policy that determines which roles are assumable. Documentation on how to configure the policy using XML and JavaScript constructs is provided below. General information on configuring role is located at the Settings for Roles page.
Invocation
At any time after a session is authenticated a request to GetAssumableRoles or the java call getAssumableRoles() may result in these rules being evaluated. Calls to other role requests such as IsInRole or ActivateRole or Activation at Authentication may also result in the assumable roles rules being evaluated. The results of the computation are cached for a time on the session.
Configuration
For an example of where this configuration should be placed in the Configuration file, see XML File Configuration Format. Under the roles element there will be an element named Assumable Roles of type htf:map, each of the siblings of Assumable Roles will be a role role and will follow the format described in Rule Format below.
<Setting Name="Roles" Type="htf:map">
<Setting Name="Assumable Roles" Type="htf:map">
<Setting Name="Role Rule 1" Type="htf:map">
....
Rule Format
Each rule under the Assumable Roles element must meet the following requirements:
- The actual name as specified by the Name attribute must be unique among its siblings. This is because duplicate names might result in one of the rules overriding the other. This name is displayed in error and debug messages.
- The rule's Type attribute must be an htf:map.
- The Enabled element is an optional element of Type xsd:boolean. If it is set to false then the rule is ignored. This option is useful for testing rules or temporarily disabling rules during testing.
- The Additive element is an optional element of Type xsd:boolean. If it is set to false then the roles computed by the rule are removed from the list. If the element is not present or the value of the element is set to true then the roles are added to the final list.
- It must have one of TokenRule or EntityAttrs or ContextFilter or NativeContextFilter elements. These are the only styles of rules that are currently supported for assumable roles computation.
TokenRule
The TokenRule is evaluated if there is no other role rule, it does not require a context or Entity within that context. When the TokenRule element is of type htf:jscriptexec, the resulting JavaScript can compute roles with any mechanism known to it. The role or list of roles may be returned using the JavaScript variable name RESULT, and be of the format described in Rule Returns. The following variables are Java objects, and are always present in the JavaScript. They may be accessed via their Java interfaces.
- authSession - The local identity service (it is of type IAuthSession).
- authMethod - The authentication method which was just authenticated (it is an !IAuthMethod).
This sample ignores the passed in authSession and token, chosing to allow every authenticated token access to three roles.
<Setting Name="TokenRule" Type="htf:jscriptexec">
var role1 = new Packages.org.bandit.otis.impl.CommonRole(
String("RandomRole1"));
role1.addPropertyValue(Packages.org.bandit.otis.api.IRole.roleTypes,
"Computed Role");
var role2 = new Packages.org.bandit.otis.impl.CommonRole(
String("RandomRole2"));
role2.addPropertyValue(Packages.org.bandit.otis.api.IRole.roleTypes,
"Computed Role");
var role3 = new Packages.org.bandit.otis.impl.CommonRole(
String("RandomRole3"));
role3.addPropertyValue(Packages.org.bandit.otis.api.IRole.roleTypes,
"Computed Role");
RESULT = java.lang.reflect.Array.newInstance( Packages.org.bandit.otis.impl.CommonRole, 4);
RESULT[0] = role1;
RESULT[1] = role2;
RESULT[2] = role3;
</Setting>
EntityAttrs
EntityAttrs rules work if the token results in a context association and a specific Entity within that context. The role or list of roles may be returned using the JavaScript variable name RESULT, and be of the format described in Rule Returns. An EntityAttrs rule has the following general properties and behaviors:
- It may be either an htf:list of sibling elements xsd:anyURI, or a single xsd:anyURI with no siblings.
- All of the attributes listed in the element are queried from Entity associated with the authenticated Token. For each attribute value returned, a role is created with the data in the attribute value used as the roleId.
- If a RoleInstantiation element exists, that policy is used to create the IRole or IRoles instead of the Rule Returns. See RoleInstantiation.
JavaScript RoleInstantiation
The RoleInstantiation element is of type htf:jscriptexec. When the JavaScript is evaluated it expects the result to be either a role or something that can be treated as a role. Returning actual roles results in properties being set properly, and may allow for additional operations on the object. This JavaScript is only invoked from EntityAttrs.
The following variables are Java objects and are always present in the JavaScript. They can be accessed via their Java interfaces, and can be used in creating the new role.
- rule - A Java map of <String, Object> that contains all of the rule elements as defined in configuration.
- entity - The IdAS IEntity object related to this token. It is from this entity that the attributes were read.
- attribute - The URI describing the attribute that was just read.
- attributeValue - The IdAS ITypedValue object for this attribute value.
- data - The raw data for the attribute value.
ContextFilter
ContextFilter of type htf:jscriptexec, this element will be evaluated and the result used as a filter in a call to .getEntities for matching elements. If a limited number of attributes are required then a sibling element named EntityAttrsFilter of the same types as EntityAttrs may be used to specify the restriction. The return from .getEntities() will be handled using the format described in Rule Returns.
NativeContextFilter
Of type htf:jscriptexec, this element will be evaluated and the result used as a native filter extension in a call to .getEntities() for matching elements. If a limited number of attributes are required then a sibling element named EntityAttrsFilter of the same types as EntityAttrs may be used to specify the restriction. The return from .getEntities() will be handled using the format described in Rule Returns.
Rule Returns
The various role rules should return a new Java object by setting the JavaScript variable name RESULT. The following could be considered valid returns:
- A single java object which implements the IRole interface. This or a list of IRoles is preferred.
- A string, this will be treated as the role identifier. The role will not have a description or other properties. If this behavior is not acceptable a sibling element of type StringToRole may be used to configure rules for transforming the entity to a role. The StringToRole may also be used if the returned string object is a delimited list which must be parsed into multiple roles.
- A higgins IEntity. The entity ID will be used as the role identifier, no other role properties will be set. If this is not acceptable a sibling element of type EntityToRole may be used to configure rules for transforming the entity to a role.
- An Iterable, or Iterator of any of the objects listed above in this list.
JavaScript EntityToRole
When the EntityToRole element is of type htf:jscriptexec, the resulting JavaScript can translate entities to roles with any mechanism known to it. The role or list of roles may be returned using the JavaScript variable name RESULT. The following variables are Java objects, and are always present in the JavaScript. They may be accessed via their Java interfaces.
- authSession - The local identity service (it is of type IAuthSession).
- rule - A Java map of <String, Object> that contains all of the rule elements as defined in configuration.
- entity - A Java object of type IEntity.
JavaScript StringToRole
When the StringToRole element is of type htf:jscriptexec, the resulting JavaScript can translate strings to roles with any mechanism known to it. The role or list of roles may be returned using the JavaScript variable name RESULT. The following variables are Java objects, and are always present in the JavaScript. They may be accessed via their Java interfaces.
- authSession - The local identity service (it is of type IAuthSession).
- rule - A Java map of <String, Object> that contains all of the rule elements as defined in configuration.
- data - A Java String.
Sample
<Setting Name="Roles" Type="htf:map">
<!-- Root most role configuration element, should be located under the OtisConfiguration element -->
<Setting Name="JSSharedScope" Type="htf:jscriptscope">
importPackage(Packages.org.bandit.otis.impl);
importPackage(Packages.org.bandit.otis.api);
.....#Other fun javascript elements here
</Setting>
<Setting Name="Assumable Roles" Type="htf:map">
<Setting Name="Role Rule 1" Type="htf:map">
<Setting Name="Enabled" Type="xsd:boolean">true</Setting>
<Setting Name="EntityAttrs" Type="htf:list">
<Setting Type="xsd:anyURI">http://www.eclipse.org/higgins/ontologies/2006/higgins/ldap#attr_objectclass</Setting>
</Setting>
<Setting Name="JSSharedScope" Type="htf:ref">/Roles/JSSharedScope</Setting>
<Setting Name="RoleInstantiation" Type="htf:jscriptexec">
RESULT = new Packages.org.bandit.otis.impl.CommonRole(
String(data));
RESULT.addPropertyValue(Packages.org.bandit.otis.api.IRole.roleTypes,
attribute.getAttrID().toString());
</Setting>
</Setting>
<Setting Name="Role Rule 3" Type="htf:map">
<Setting Name="Enabled" Type="xsd:boolean">true</Setting>
<Setting Name="EntityAttrs" Type="htf:list">
<Setting Type="xsd:anyURI">http://burtongroup.com/interop/2007/05/identity/group</Setting>
<Setting Type="xsd:anyURI">http://burtongroup.com/interop/2007/05/identity/groupRole</Setting>
</Setting>
<Setting Name="JSSharedScope" Type="htf:ref">/Roles/JSSharedScope</Setting>
<Setting Name="RoleInstantiation" Type="htf:jscriptexec">
RESULT = new Packages.org.bandit.otis.impl.CommonRole(
String(data));
RESULT.addPropertyValue(Packages.org.bandit.otis.api.IRole.roleTypes,
"Membership Roles");
</Setting>
</Setting>
<Setting Name="Role Rule 4" Type="htf:map">
<Setting Name="Enabled" Type="xsd:boolean">true</Setting>
<Setting Name="JSSharedScope" Type="htf:ref">/Roles/JSSharedScope</Setting>
<Setting Name="TokenRule" Type="htf:jscriptexec">
var role1 = new Packages.org.bandit.otis.impl.CommonRole(
String("RandomRole1"));
role1.addPropertyValue(Packages.org.bandit.otis.api.IRole.roleTypes,
"Computed Role");
var role2 = new Packages.org.bandit.otis.impl.CommonRole(
String("RandomRole2"));
role2.addPropertyValue(Packages.org.bandit.otis.api.IRole.roleTypes,
"Computed Role");
var role3 = new Packages.org.bandit.otis.impl.CommonRole(
String("RandomRole3"));
role3.addPropertyValue(Packages.org.bandit.otis.api.IRole.roleTypes,
"Computed Role");
RESULT = java.lang.reflect.Array.newInstance( Packages.org.bandit.otis.impl.CommonRole, 4);
RESULT[0] = role1;
RESULT[1] = role2;
RESULT[2] = role3;
</Setting>
</Setting>
</Setting> <!-- End Assumable Roles -->
...........