This chapter provides information and procedures for performing a range of administrative-level tasks in the Waveset system, such as creating and managing Waveset administrators and organizations. It also provides an understanding of how you can use roles, capabilities, and administrative roles in Waveset.
The information is grouped in the following topics:
Waveset administrators are users with extended Waveset privileges.
Waveset administrators manage:
User accounts
System objects, such as roles and resources
Organizations
Unlike users, administrators in Waveset are assigned capabilities and controlled organizations, which are defined as follows:
Capabilities. A set of permissions granting access rights to Waveset users, organizations, roles, and resources.
Controlled organizations. Once assigned to control an organization, the administrator can manage the objects in that organization, as well as any organizations that are descended from it in the hierarchy.
In most companies, employees who perform administrative tasks hold specific responsibilities. Consequently, the account management tasks that these administrators can perform are limited in scope.
For example, an administrator might be responsible only for creating Waveset user accounts. With that limited scope of responsibility, the administrator likely does not need specific information about the resources on which user accounts are created, or about the roles or organizations that exist within the system.
Waveset can also restrict administrators to a specific tasks within a specific, defined scope.
Waveset supports the separation of responsibilities and a delegated administration model as follows:
Assigned capabilities limit administrators to specific job duties
Assigned controlled organizations restrict administrators to controlling only specific organizations (and the objects within those organizations)
Filtered views of the Create User and Edit User pages prevent administrators from viewing information that is not relevant to their job duties
You can specify delegations for a user from the Create User page when you set up a new user account, or when you edit a user account.
You can also delegate work items, such as requests for approvals, from the Work Items tab. For more information on delegations, see Delegating Work Items for details.
This section is organized into the following topics:
To create an administrator, assign one or more capabilities to a user and designate the organizations to which the capabilities will apply.
In the Administrator interface, click Accounts in the menu bar.
The User List page opens.
To give an existing user administrative privileges, click the user name (the Edit User page opens), then click the Security tab.
If a new user account needs to be created, see Creating Users and Working with User Accounts.
Specify attributes to establish administrative control.
Available attributes include:
Capabilities. Select one or more capabilities that should be assigned to this administrator. This information is required. For more information, see Understanding and Managing Capabilities.
Controlled Organizations. Select one or more organizations that should be assigned to the administrator. The administrator will control objects in the assigned organization and in any organizations beneath it in the hierarchy. This information is required. For more information, see Understanding Waveset Organizations.
User Form. Select the user form that this administrator will use when creating and editing Waveset users (if that capability is assigned). If you do not directly assign a user form, the administrator will inherit the user form assigned to the organization he belongs to. The form selected here supersedes any form selected within this administrator’s organization.
Forward Approval Requests To. Select a user to forward all current pending approval requests to that user. This administrator setting also can be set from the Approvals page.
Delegate Work Items To. If available, use this option to specify delegations for this user account. You can specify the administrator’s manager, one or more selected users, or use a delegate approvers rule.
By assigning user forms to organizations and administrators, you establish specific administrator views of user information.
Access to user information is set at two levels:
Organization. When you create an organization, you assign the user form that all administrators in that organization will use when creating and editing Waveset users. Any form set at the administrator level overrides the form set here. If no form is selected for the administrator or the organization, Waveset inherits the form selected for the parent organization. If no form is set there, Waveset uses the default form set in the system configuration.
Administrator. When you assign a user administrative capabilities, you can directly assign a user form to the administrator. If you do not assign a form, the administrator inherits the form assigned to his organization (or the default form set in the system configuration if no form is set for the organization).
Understanding and Managing Capabilities describes built-in Waveset capabilities that you can assign.
Administrator passwords may be changed by an administrator with administrative password change capabilities assigned, or by the administrator-owner.
Administrators can change another administrator’s password using these forms:
Change User Password form. There are two ways to open this form:
Click Accounts in the menu. The User List opens. Select an administrator and then, in the User Actions list, select Change Password. The Change User Password page opens.
Click Passwords in the menu. The Change User Password page opens.
Tabbed User form. Click Accounts in the menu. The User List opens. Select an administrator, and then, in the User Actions menu, select Edit. The “Edit User” page (Tabbed User Form) opens. On the Identity form tab, type a new password in the Password and Confirm Password fields.
An administrator can change his own password from the Passwords area. Click Passwords in the menu, then click Change My Password.
The Waveset account policy applied to the account determines password limitations, such as password expiration, reset options, and notification selections. Additional password limitations may be set by password policies set on the administrator’s resources.
Waveset can be configured to prompt administrators for a password before processing certain account changes. If authentication fails, then the account changes will be cancelled.
There are three forms that administrators can use to change user passwords. These are the Tabbed User form, the Change User Password form, and the Reset User Password form. To ensure that administrators are required to enter their password before Waveset processes user account changes, be sure to update all three forms.
To require a password challenge on the Tabbed User form, follow these steps.
In the Administrator interface, open the Waveset debug page (The Waveset Debug Page) by typing the following URL into your browser. (You must have the Debug capability to open this page.)
http://<AppServerHost>:<Port>/idm/debug/session.jsp
The System Settings page (Waveset debug page) opens.
Find the List Objects button, select UserForm from the drop-down menu, then click the ListObjects button.
The List Objects of type: UserForm page opens.
Locate the copy of the Tabbed User Form that you have in production and click edit. (The Tabbed User Form distributed with Waveset is a template and should not be modified.)
Add the following code snippet inside the <Form> element:
<Properties> <Property name=’RequiresChallenge’> <List> <String>password</String> <String>email</String> <String>fullname</String> </List> </Property> </Properties> |
The property value is a list that can contain one or more of the following user view attribute names:
applications
adminRoles
assignedLhPolicy
capabilities
controlledOrganizations
firstname
fullname
lastname
organization
password
resources
roles
Save your changes.
To require a password challenge on the Change User Password and Reset User Password forms, follow these steps:
In the Administrator interface, open the Waveset debug page (The Waveset Debug Page) by typing the following URL into your browser. (You must have the Debug capability to open this page.)
http://<AppServerHost>:<Port>/idm/debug/session.jsp
The System Settings page (Waveset debug page) opens.
Locate the List Objects button, select UserForm from the drop-down menu, then click the ListObjects button.
The List Objects of type: UserForm page opens.
Locate the copy of the Change Password User Form that you have in production and click edit. (The Change Password User Form distributed with Waveset is a template and should not be modified.)
Locate the <Form> element, then go to the <Properties> element.
Add the following line inside the <Properties> element and save your changes.
<Property name=’RequiresChallenge’ value=’true’/>
Repeat steps 3 - 5, except edit the copy of the “Reset User Password Form” that you have in production.
Use the Passwords area to change the answers you have set for account authentication questions. From the menu bar, select Passwords, and then select Change My Answers.
For more information about authentication, see the Setting Account Authentication Policies section in Chapter 3, User and Account Management.
You can display an Waveset administrator by attribute (such as email or fullname) rather than by accountId in some Waveset Administrator interface pages and areas.
For example, you can display Waveset administrators by attribute in the following areas:
Edit User (forward approvals selection list)
Role table
Create/Edit Role
Create/Edit Resource
Create/Edit Organization/Directory Junction
Approvals
To configure Waveset to use a display name, add to the UserUIConfig object:
<AdminDisplayAttribute> <String>attribute_name</String> </AdminDisplayAttribute>
For example, to use the email attribute as the display name, add the following attribute name to UserUIconfig:
<AdminDisplayAttribute> <String>email</String> </AdminDisplayAttribute>
Organizations allow you to:
Logically and securely manage user accounts and administrators
Limit access to resources, applications, roles, and other Waveset objects
By creating organizations and assigning users to various locations in an organizational hierarchy, you set the stage for delegated administration. Organizations that contain one or more other organizations are called parent organizations.
All Waveset users (including administrators) are statically assigned to one organization. Users also can be dynamically assigned to additional organizations.
Waveset administrators are additionally assigned to control organizations.
Create organizations in the Waveset Accounts area.
In the Administrator interface, click Accounts in the menu bar.
The User List page opens.
In the New Actions menu, select New Organization.
To create an organization at a specific location in the organizational hierarchy, select an organization in the list, and then select New Organization in the New Actions menu.
Figure 6–1 illustrates the Create Organization page.
Each user is a static member of one organization, and can be a dynamic member of more than one organization.
You define organizational memberships using either of the following methods:
Direct (static) assignment. Select the Identity form tab on the Create User page or Edit User page to assign users directly to an organization. A user must be directly assigned to one organization.
Rule-driven (dynamic) assignment. Use a User Members Rule that is assigned to an organization to assign users to that organization. The rule, when evaluated, returns a set of member users.
Waveset evaluates the User Members Rule when:
Listing the users in an organization
Finding users (through the Find Users page) that includes searching for users that are in an organization with a User Members Rule
Requesting access to a user, provided that the current administrator controls an organization with a User Members Rule
For more information about creating and working with rules in Waveset, see Chapter 4, Working with Rules, in Oracle Waveset 8.1.1 Deployment Reference.
Select a User Members Rule from the User Members Rule menu on the Create Organization page. The following figure shows an example User Members Rule.
The following example illustrates the syntax for a sample User Members Rule used to dynamically control an organization’s user membership.
Before creating a User Members Rule, you should be aware of the following:
For a rule to appear in the User Members Rule option box, its authType must be set as authType=’UserMembersRule’.
The context is the currently authenticated Waveset user’s session.
The defined variable (defvar) Team players gets the distinguished name (dn) for each user that is a member of the Windows Active Directory organization unit (ou) Pro Ball Team.
For each user found, the append logic will concatenate the dn of each member user of the Pro Ball Team ou with the name of the Waveset Resource prefixed by a colon (as in :smith-AD).
The results returned will be a list of dn’s concatenated with the Waveset resource name in the format dn:smith-AD.
<Rule name=’Get Team Players’ authType=’UserMembersRule’> <defvar name=’Team players’> <block> <defvar name=’player names’> <list/> </defvar> <dolist name=’users’> <invoke class=’com.waveset.ui.FormUtil’ name=’getResourceObjects’> <ref>context</ref> <s>User</s> <s>singleton-AD</s> <map> <s>searchContext</s> <s>OU=Pro Ball Team,DC=dev-ad,DC=waveset,DC=com</s> <s>searchScope</s> <s>subtree</s> <s>searchAttrsToGet</s> <list> <s>distinguishedName</s> </list> </map> </invoke> <append name=’player names’> <concat> <get> <ref>users</ref> <s>distinguishedName</s> </get> <s>:sampson-AD</s> </concat> </append> </dolist> <ref>player names</ref> </block> </defvar> <ref>Team players</ref> </Rule>
You can configure several properties in Waveset. properties to control the rule-driven User Members list cache, which can affect memory and performance. For information, see Tracing Rule-Driven Members Caches in Oracle Waveset 8.1.1 System Administrator’s Guide.
Assign administrative control of one or more organizations from the Create User page or Edit User page. Select the Security form tab to display the Controlled Organizations field.
You can also assign administrative control of organizations by assigning one or more admin roles, from the Admin Roles field.
A directory junction is a hierarchically related set of organizations that mirrors a directory resource’s actual set of hierarchical containers. A directory resource is one that employs a hierarchical namespace through the use of hierarchical containers. Examples of directory resources include LDAP servers and Windows Active Directory resources.
Each organization in a directory junction is a virtual organization. The topmost virtual organization in a directory junction is a mirror of the container representing the base context defined in the resource. The remaining virtual organizations in a directory junction are direct or indirect children of the top virtual organization, and also mirror one of the directory resource containers that are children of the defined resource’s base context container. This structure is illustrated in Figure 6–2.
Directory junctions can be spliced into the existing Waveset organizational structure at any point. However, directory junctions cannot be spliced within or below an existing directory junction.
Once you have added a directory junction to the Waveset organizational tree, you can create or delete virtual organizations in the context of that directory junction. In addition, you can refresh the set of virtual organizations comprising a directory junction at any time to ensure they stay synchronized with the directory resource containers. You cannot create a non-virtual organization within a directory junction.
You can make Waveset objects (such as users, resource, and roles) members of, and available to, a virtual organization in the same way as an Waveset organization.
This section describes how to set up a directory junction.
In the Administrator interface, select Accounts in the menu bar.
The User List page opens.
Select an Waveset organization in the Accounts list.
The organization you select will be the parent organization of the virtual organization you set up.
In the New Actions menu, select New Directory Junction.
Waveset opens the Create Directory Junction page.
Use the options on the Create Directory Junction page to set up the virtual organization.
These options include:
Parent organization. This field contains the organization you selected from the Accounts list; you can, however, select a different parent organization from the list.
Directory resource. Select the directory resource that manages the existing directory whose structure you want to mirror in the virtual organization.
User form. Select a user form that will apply to administrators in this organization.
Waveset account policy. Select a policy, or select the default option (inherited) to inherit the policy from the parent organization.
Approvers. Select administrators who can approve requests related to this organization.
This process refreshes and re-synchronizes the virtual organization with the associated directory resource, from the selected organization down. Select the virtual organization in the list, and then select Refresh Organization from the Organization Actions list.
When deleting virtual organizations, you can select from two delete options:
Delete the Waveset organization only. Deletes the Waveset directory junction only.
Delete the Waveset organization and the resource container. Deletes the Waveset directory junction and the corresponding organization on the native resource.
Select an option, and then click Delete.
Capabilities are groups of rights in the Waveset system. Capabilities represent administrative job responsibilities, such as resetting passwords or administering user accounts. Each Waveset administrative user is assigned one or more capabilities, which provide a set of privileges without compromising data protection.
Not all Waveset users need capabilities assigned. Only those users who will perform one or more administrative actions through Waveset will require capabilities. For example, an assigned capability is not needed to enable a user to change his password, but an assigned capability is required to change another user’s password.
Your assigned capabilities govern which areas of the Waveset Administrator Interface you can access.
All Waveset administrative users can access certain areas of Waveset, including:
Home and Help tabs
Passwords tab (Change My Password and Change My Answers subtabs only)
Reports (limited to types related to the administrator’s specific responsibilities)
A list of Waveset’s default task-based and functional capabilities (with definitions) is included in Appendix D, Capabilities Definitions. This appendix also lists the tabs and subtabs that may be accessed with each task-based capability.
Waveset defines Capabilities as:
Task-based. These are capabilities at their simplest task level.
Functional. Functional capabilities contain one or more other functional or task-based capabilities.
Built-in capabilities (those provided with the Waveset system) are protected, meaning that you cannot edit them. You can, however, use them within capabilities that you create.
Protected (built-in) capabilities are indicated in the list with a red key (or red key and folder) icon. Capabilities that you create and can edit are indicated in the capabilities list with a green key (or green key and folder) icon.
This section describes how to create, edit, assign, and rename capabilities. These tasks are performed using the Capabilities page.
The Capabilities page is found under the Security tab.
In the Administrator interface, click Security in the top menu.
Click Capabilities in the secondary menu.
The Capabilities page opens and shows a list of Waveset capabilities.
Use the following procedure to create a capability. To clone a capability, see Save and Rename a Capability.
In the Administrator interface, click Security in the top menu.
Click Capabilities in the secondary menu.
The Capabilities page opens and shows a list of Waveset capabilities.
Click New.
The Create Capability page opens.
Complete the form as follows:
Name the new capability.
In the Capabilities section, use the arrow buttons to move the capabilities that should be assigned to users into the Assigned Capabilities box.
In the Assigners box, select one or more users that will be allowed to assign this capability to other users.
If no users are selected, the only user who can assign this capability is the one that created the capability.
If the user who created the capability does not have the Assign User Capability capability assigned, then you must select one or more users to ensure that at least one user can assign the capability to another user.
In the Organizations box, select one or more organizations to which this capability will be available.
Click Save.
The set of users from which you can make assigner selections are those who have been assigned the Assign Capability right.
You can edit a non-protected capability.
In the Administrator interface, click Security in the top menu.
Click Capabilities in the secondary menu.
The Capabilities page opens and shows a list of Waveset capabilities.
Right-click the capability in the list, and then select Edit. The Edit Capability page opens.
Make your changes and click Save.
You cannot edit built-in capabilities. You can, however, save them with a different name in order to create your own capability. You can also use built-in capabilities in capabilities that you create.
You can create a new capability by saving an existing capability with a new name. This process is known as cloning the capability.
In the Administrator interface, click Security in the top menu.
Click Capabilities in the secondary menu.
The Capabilities page opens and shows a list of Waveset capabilities.
Right-click the capability in the list, and then select Save As.
A dialog box opens and asks you to type a name for the new capability.
Type a name and click OK.
You can now edit the new capability.
Use the Create User page (Creating Users and Working with User Accounts) or the Edit User page (Editing Users) to assign capabilities to users. You can also assign capabilities to a user by assigning an administrator role, which you set up through the Security area in the interface. See Understanding and Managing Admin Roles for more information.
A list of Waveset’s default task-based and functional capabilities (with definitions) is included in Appendix D, Capabilities Definitions. This appendix also lists the tabs and subtabs that may be accessed with each task-based capability.
Admin Roles define two things: a set of capabilities and a scope of control. (The term scope of control refers to one or more managed organizations.) Once defined, admin roles can then be assigned to one or more administrators.
Do not confuse roles with admin-roles. Roles are used to manage end-users’ access to external resources, whereas admin-roles are primarily used to manage Waveset administrator access to Waveset objects.
The information presented in this section is limited to admin roles. For information about roles, see Understanding and Managing Roles.
Multiple admin roles can be assigned to a single administrator. This enables an administrator to have one set of capabilities in one scope of control, and a different set of capabilities in another scope of control. For example, one admin role might grant the administrator the right to create and edit users for the controlled organizations specified in that admin role. A second admin role assigned to the same administrator, however, might grant only the “change users’ passwords” right in a separate set of controlled organizations as defined in that admin role.
Admin roles enable the reuse of capabilities and scope-of-control pairings. Admin roles also simplify the management of administrator privileges across a large number of users. Instead of directly assigning capabilities and controlled organizations to individual users, admin roles should be used to grant administrator privileges.
The assignment of capabilities or organizations (or both) to an admin role can be either direct or dynamic (indirect).
Direct. Using this method, capabilities and/or controlled organizations are explicitly assigned to the admin role. For example, an admin role might be assigned the User Report Administrator capability and the controlled organization Top.
Dynamic (indirect). This method uses rules to assign capabilities and controlled organizations. Rules are evaluated each time an administrator assigned the admin role logs in. Once an administrator is authenticated, rules dynamically determine which set of capabilities and/or controlled organizations are assigned.
For example, when a user logs in:
If his Active Directory (AD) user title is manager, then the capabilities rule might return Account Administrator as the capability to be assigned.
If his Active Directory (AD) user department is marketing, then the controlled organizations rule might return Marketing as the controlled organization to be assigned.
The dynamic assignment of admin roles to users can be enabled or disabled for each login interface (for example, the User interface or Administrator interface). To do this, set the following system configuration attribute to true or false:
security.authz.checkDynamicallyAssignedAdminRolesAtLoginTo.logininterface
The default for all interfaces is false.
For instructions on editing the system configuration object, see Editing Waveset Configuration Objects.
Waveset provides sample rules that you can use to create rules for Admin Roles. These rules are available in the Waveset installation directory in sample/adminRoleRules.xml.
Table 6–1 provides the rule names and the authType you must specify for each rule.
Table 6–1 Admin Role Sample Rules
Rule Name |
authType |
---|---|
Controlled Organizations Rule |
ControlledOrganizationsRule |
Capabilities Rule |
CapabilitiesRule |
User Is Assigned Admin Role Rule |
UserIsAssignedAdminRoleRule |
For information about the sample rules provided for service provider users admin roles, see Delegated Administration for Service Provider Users in Chapter Chapter 17, Service Provider Administration.
Waveset includes a built-in admin role, named User Admin Role. By default, it has no assigned capabilities or controlled organization assignments. It cannot be deleted. This admin role is implicitly assigned to all users (end-users and administrators) at login time, regardless of the interface they log in to (for example, user, administrator, console, or Identity Manager IDE).
For information about creating an admin role for service provider users, see Delegated Administration for Service Provider Users in ChapterChapter 17, Service Provider Administration.
You can edit the User Admin Role through the Administrator interface (select Security, and then select Admin Roles).
Because any capabilities or controlled organizations that are statically assigned through this admin role are assigned to all users, it is recommended that the assignment of capabilities and controlled organizations be done through rules. This will enable different users to have different (or no) capabilities, and assignments will be scoped depending on factors such as who they are, which department they are in, or whether they are managers, which can be queried for within the context of the rules.
The User Admin Role does not deprecate or replace the use of the authorized=true flag used in workflows. This flag is still appropriate in cases where the user should not have access to objects accessed by the workflow, except when the workflow is executing. Essentially, this lets the user enter a run as superuser mode.
There may be cases, however, where a user should have specific access to one or more objects outside of (and potentially inside of) workflows. In these cases, using rules to dynamically assign capabilities and controlled organizations allows for fine-grain authorization to those objects.
To create or edit an admin role, you must be assigned the Admin Role Administrator capability.
To access admin roles in the Administrator interface, click Security, and then click the Admin Roles tab. The Admin Roles list page allows you to create, edit, and delete admin roles for Waveset users and for service provider users.
To edit an existing admin role, click a name in the list. Click New to create an admin role. Waveset displays the Create Admin Role options (illustrated in Figure 6–3). The Create Admin Role view presents four tabs that you use to specify the general attributes, capabilities, and scope of the new admin role, as well as assignments of the role to users.
Use the General tab of the create admin role or edit admin role view to specify the following basic characteristics of the admin role:
Name. A unique name for this admin role.
For example, you might create the Finance Admin Role for users who will have administrative capabilities for users in the Finance department (or organization).
Type. Select either Identity Objects or Service Provider Users for the type. This field is required.
Select Identity Objects if you are creating an admin role for Waveset users (or objects). Select Service Provider Users if you are creating the admin role to grant access to service provider users.
For information about creating an admin role to grant access to service provider users, see Delegated Administration for Service Provider Users in Chapter Chapter 17, Service Provider Administration.
Assigners. Select or search for users that will be allowed to assign this admin role to other users. The set of users from which you can make selections includes those who have been assigned the Assign Capability right.
If no users are selected, the only user who will be able to assign the admin role is the one that created it. If the user who created the admin role does not have the Assign User Capabilities capability assigned, then select one or more users as Assigners to ensure that at least one user can assign the admin role to another user.
Organizations. Select one or more organizations to which this admin role will be available. This field is required.
The administrator can manage objects in the assigned organization and in any organizations below that organization in the hierarchy.
Waveset allows you to control which users are within an end user’s scope of control.
Use the Scope of Control tab (shown in Figure 6–4) to specify organizations that members of this organization can manage, or to specify the rule that determines the organizations to be managed by users of the admin role, and to select the user form for the admin role.
Controlled Organizations. Select from the Available Organizations list the organizations that this admin role has the rights to manage.
Controlled Organizations Rule. Select a rule that will be evaluated, at user login, to zero or more organizations to be controlled by a user assigned this admin role. The selected rule must have the ControlledOrganizationsRule authType. By default, no controlled organization rule is selected.
You can use the EndUserControlledOrganizations rule to define whatever logic is necessary to ensure the right set of users are available for delegating, based on your organizational needs.
If you want the scoped list of users to be the same for administrators, whether they are logged into the Administrator interface or the End User interface, you must change the EndUserControlledOrganizations rule.
Modify the rule to first check whether the authenticating user is an administrator, and then configure the following:
If the user is not an administrator, return the set of organizations that should be controlled by an end user, such as the user’s own organization (for example, waveset.organization).
If the user is an administrator, do not return any organizations so the user only controls organizations that are assigned because that user is an administrator.
For example:
<Rule protectedFromDelete=’true’ authType=’EndUserControlledOrganizationsRule’ id=’#ID#End User Controlled Organizations’ name=’End User Controlled Organizations’> <Comments> If the user logging in is not an Idm administrator, then return the organization that they are a member of. Otherwise, return null. </Comments> <cond> <and> <isnull><ref>waveset.adminRoles</ref></isnull> <isnull><ref>waveset.capabilities</ref></isnull> <isnull><ref>waveset.controlledOrganizations</ref></isnull> </and> <ref>waveset.organization</ref> </cond> <MemberObjectGroups> <ObjectRef type=’ObjectGroup’ id=’#ID#Top’ name=’Top’/> </MemberObjectGroups> </Rule> |
If the user or administrator belongs to a dynamic organization, they are not returned in search results.
However, you can create a rule to return users in dynamic organizations. Change the following sample rule by adding a new attribute to the Waveset user schema definition that is defined in the Idm Schema Configuration object, import that object, and then restart the Waveset server.
<IDMAttributeConfigurations> ... <IDMAttributeConfiguration name='region' syntax='STRING' description='region of the country'/> </IDMAttributeConfigurations> <IDMObjectClassConfigurations> ... <IDMObjectClassConfiguration name='User' extends='Principal' description='User description'> ... <IDMObjectClassAttributeConfiguration name='region' queryable='true'/> </IDMObjectClassConfiguration> </IDMObjectClassConfigurations> Next, import the following Waveset objects: <!-- User member rule that will include all users whose region attribute matches the region organization display name --> <Rule name="Region User Member Rule" authType="UserMembersRule"> <Description>User Member Rule</Description> <list> <new class='com.waveset.object.AttributeCondition'> <s>region</s> <s>equals</s> <ref>userMemberRuleOrganizationDisplayName</ref> </new> </list> <MemberObjectGroups> <ObjectRef type="ObjectGroup" id="#ID#All" name="All"/> </MemberObjectGroups> </Rule> <!-- North & South Region organizations with user member rule assigned --> <ObjectGroup id='#ID#North Region' name='North Region' displayName='North Region'> <UserMembersRule cacheTimeout='3600000'> <ObjectRef type='Rule' name='Region User Member Rule'/> </UserMembersRule> <MemberObjectGroups> <ObjectRef type='ObjectGroup' name='Top' id='#ID#Top'/> </MemberObjectGroups> </ObjectGroup> <ObjectGroup id='#ID#South Region' name='South Region' displayName='South Region'> <UserMembersRule cacheTimeout='3600000'> <ObjectRef type='Rule' name='Region User Member Rule'/> </UserMembersRule> <MemberObjectGroups> <ObjectRef type='ObjectGroup' name='Top' id='#ID#Top'/> </MemberObjectGroups> </ObjectGroup> <!-- Organization containing all employees --> <ObjectGroup id='#ID#Employees' name='Employees' displayName='Employees'> <MemberObjectGroups> <ObjectRef type='ObjectGroup' name='Top' id='#ID#Top'/> </MemberObjectGroups> </ObjectGroup> <!-- End user controlled organization rule that give each user control of the regional organization they are a member of --> <Rule protectedFromDelete='true' authType='EndUserControlledOrganizationsRule' id='#ID#End User Controlled Organizations' name='End User Controlled Organizations' primaryObjectClass='Rule'> <switch> <ref>waveset.attributes.region</ref> <case> <s>North Region</s> <s>North Region</s> </case> <case> <s>South Region</s> <s>South Region</s> </case> <case> <s>East Region</s> <s>East Region</s> </case> <case> <s>West Region</s> <s>West Region</s> </case> </switch> <MemberObjectGroups> <ObjectRef type='ObjectGroup' id='#ID#Top' name='Top'/> </MemberObjectGroups> </Rule> <!-- 4 employees (2 in North and 2 in South region) --> <User name='emp1' primaryObjectClass='User' asciipassword='1111'> <Attribute name='firstname' type='string' value='Employee'/> <Attribute name='fullname' type='string' value='Employee One'/> <Attribute name='lastname' type='string' value='One'/> <Attribute name='region' type='string' value='North Region'/> <MemberObjectGroups> <ObjectRef type='ObjectGroup' id='#ID#Employees' name='Employees' displayName='Employees'/> </MemberObjectGroups> </User> <User name='emp2' primaryObjectClass='User' asciipassword='1111'> <Attribute name='firstname' type='string' value='Employee'/> <Attribute name='fullname' type='string' value='Employee Two'/> <Attribute name='lastname' type='string' value='Two'/> <Attribute name='region' type='string' value='North Region'/> <MemberObjectGroups> <ObjectRef type='ObjectGroup' id='#ID#Employees' name='Employees' displayName='Employees'/> </MemberObjectGroups> </User> <User name='emp4' primaryObjectClass='User' asciipassword='1111'> <Attribute name='firstname' type='string' value='Employee'/> <Attribute name='fullname' type='string' value='Employee Four'/> <Attribute name='lastname' type='string' value='Four'/> <Attribute name='region' type='string' value='South Region'/> <MemberObjectGroups> <ObjectRef type='ObjectGroup' id='#ID#Employees' name='Employees' displayName='Employees'/> </MemberObjectGroups> </User> <User name='emp5' primaryObjectClass='User' asciipassword='1111'> <Attribute name='firstname' type='string' value='Employee'/> <Attribute name='fullname' type='string' value='Employee Five'/> <Attribute name='lastname' type='string' value='Five'/> <Attribute name='region' type='string' value='South Region'/> <MemberObjectGroups> <ObjectRef type='ObjectGroup' id='#ID#Employees' name='Employees' displayName='Employees'/> </MemberObjectGroups> </User> |
Next, log in through the Waveset End User interface as emp1, who is in the North region. Select Delegations -> New. Change the search -> provide criteria to Starts with, change the value to emp, and choose Find. This selection should return emp2 in the list of available users.
Controlled Organizations User Form. Select a user form that a user who is assigned this admin role will use when he creates or edits users who are members of this admin role’s controlled organizations. By default, no Controlled Organizations User Form is selected.
A user form assigned through an admin role overrides any user form that is inherited from the organization of which the administrator is a member. It does not override a user form that is directly assigned to the admin.
Capabilities assigned to the admin role determine what administrative rights users assigned the admin role have. For example, this admin role might be restricted to creating users only for the controlled organizations of the admin role. In that case, you assign the Create User capability.
On the Capabilities tab, select the following options:
Capabilities. These are specific capabilities (administrative rights) that the users of the admin role will have for their controlled organizations. Select one or more capabilities from the list of available capabilities and move them to the Assigned Capabilities list.
Capabilities Rule. Select a rule that when evaluated at user login, will determine the list of zero or more capabilities granted to users assigned the admin role. The selected rule must have the CapabilitiesRule authType.
You can specify a user form to for the members of an admin role. Use the Assign To Users tab on the create admin role or edit admin role view to specify the assignments.
The administrator assigned the admin role will use this user form when creating or editing users in the organizations controlled by that admin role. A user form assigned through an admin role overrides any user form that is inherited from the organization of which the admin is a member. This user form does not override a user form that is directly assigned to the admin.
The user form that is used when editing a user is determined in this order of precedence:
If a user form is assigned directly to the admin, then it is used.
If no user form is assigned directly to the admin, but the admin is assigned an admin role that controls the organization of which the user being created or edited is a member and specifies a user form, then that user form is used.
If no user form is assigned directly to the admin, or assigned indirectly through an admin role, then the user form assigned to the admin’s member organizations (starting with the admin’s member organization and going up to just below Top) is used.
If none of the admin’s member organizations are assigned a user form, then the default user form is used.
If an admin is assigned more than one admin role that controls the same organization but specifies different user forms, then an error is displayed when he attempts to create or edit a user in that organization. If an admin attempts to assign two or more admin roles that control the same organization but specify different user forms, then an error is displayed. Changes cannot be saved until the conflict is resolved.
The End User organization provides a convenient way for administrators to make certain objects, such as resource and roles, available to end-users. End-users can view and potentially assign designated objects to themselves (pending an approval process) using the end-user interface (Logging in to the Waveset End-User Interface).
The End User organization was introduced in Waveset Version 7.1.1.
Previously, in order to grant end-users access to Waveset configuration objects, such as Roles, Resources, Tasks, and so on, administrators had to edit configuration objects and use End User Tasks, End User Resources, and End User authTypes.
Going forward, Oracle recommends using the “End User” organization to give end-users access to Waveset configuration objects.
The End User organization is implicitly controlled by all users, and enables them to view several types of objects, including tasks, rules, roles, and resources. Initially, however, the organization has no member objects.
The End User organization is a member of Top and cannot have child organizations. In addition, the End User organization is not displayed in the Accounts page list. When editing objects (such as Roles, AdminRoles, Resources, Policy, Tasks, and so on), however, you can make any object available to the End User organization using the Administrator user interface.
When end-users log in to the end-user interface, the following happens:
End-users are granted control of the EndUser organization (ObjectGroup).
Waveset evaluates the built-in End User Controlled Organization rule, which automatically gives the user control of any organization names that are returned by the rule. (This rule was added in Waveset Version 7.1.1. See the The End User Controlled Organization Rulesection for more information.)
End-users are granted rights to the object types specified in the EndUser capability.
The input argument to the End User Controlled Organization rule is the authenticating user’s view. Waveset expects the rule to return one or more organizations that the user logging in to the End User interface will control. Waveset expects the rule to return either a string (for a single organization) or a list (for multiple organizations).
To manage these objects, users need the End User Administrator capability. Users who are assigned the End User Administrator capability can view and modify the contents of the End User Controlled Organization rule. These users can also view and modify the object types specified in the EndUser capability.
The End User Administrator capability is assigned to the Configurator user by default. Any changes made to the list or to organizations returned by the evaluation of the End User Controlled Organization rule will not be reflected dynamically for logged in users. These users must log out and then log in again to see the changes.
If the End User Controlled Organization rule returns an invalid organization (for example, an organization that does not exist in Waveset), the problem will be logged in the System Log. To correct the problem, log in to the Administrator user interface and fix the rule.
Some workflow processes generated by tasks in Waveset create action items or work items. These work items might be a request for approval or some other action request assigned to an Waveset account.
Waveset groups all work items in the Work Items area of the interface, enabling you to view and respond to all pending requests from one location.
A work item might be one of the following types:
Approvals. Requests for approvals of new accounts or changes to accounts.
Attestations. Requests to review and approve user entitlements.
Remediations. Requests to remediate or mitigate user account policy violations.
Other. Action item request for other than one of the standard types. This might be an action request generated from a customized workflow.
To view pending work items for each work item type, click Work Items in the menu.
If you are a work item owner with pending work items (or delegated work items), then your Work Items list is displayed when you log into the Waveset User interface.
To respond to a work item request, click one of the work item types in the Work Items area of the interface. Select items from the list of requests and then click one of the buttons available to indicate the action you want to take. The work item options vary depending on the work item type.
For more information about responding to requests, see the following topics:
Use the History tab in the Work Items area to view the results of previous work item actions.
Figure 6–5 displays a sample view of Work Item history.
Work item owners can manage work loads by delegating work items to other users for a specified period of time. From the main menu, you can use the Work Items -> Delegate My Work Items page to delegate future work items (such as requests for approval) to one or more users (delegates). Users do not need approver capabilities to be delegates.
The delegation feature applies only to future work items. Existing items (those listed under My Work Items must be selectively forwarded through the forwarding feature.
There are other pages from which you can delegate work items:
In the Administrator interface, you can delegate work items from the Create User and Edit User pages (The User Pages (Create/Edit/View)). Click the Delegations form tab.
In the end-user User Interface (Waveset End-User Interface), users can click the Delegations menu item.
Delegates can approve work items on a work item owner’s behalf during the effective delegation period. Delegated work items include the name of the delegate.
Any user can create one or more delegations for their future work items. Administrators who can edit a user can also create a delegation on that user’s behalf. An administrator cannot, however, delegate to someone that the user cannot delegate to. (With regards to delegations, the administrator’s scope of control is the same as the user on whose behalf the delegation is being made.)
Audit log entries list the delegator’s name when delegated work items are approved or rejected. Changes to a user’s delegate approver information are logged in the detailed changes section of the audit log entry when a user is created or modified.
View delegations on the Current Delegations page.
In the Administrator interface, click Work Items in the main menu.
Click Delegate My Work Items in the secondary menu.
Waveset displays the Current Delegations page, where you can view and edit delegations currently in effect.
View previous delegations on the Previous Delegations page.
In the Administrator interface, click Work Items in the main menu.
Click Delegate My Work Items in the secondary menu.
The Current Delegations page opens.
Click Previous.
The Previous Delegations page opens. Previously delegated work items can be used to set up new delegations.
Create a delegation using the New Delegation page.
In the Administrator interface, click Work Items in the main menu.
Click Delegate My Work Items.
The Current Delegations page opens.
Click New.
The New Delegation page opens.
Complete the form as follows:
Select a work item type from the Select Work Item Type to Delegate selection list. To delegate all of your work items, select All Work Item Types.
If you are delegating a role-type, organization, or resource work-item, specify the specific roles, organizations, or resources that should define this delegation by using the arrows to move selections from the Available column to the Selected column.
Delegate Work Items To.
Select one of the following options:
Selected Users. Select to search for users in your scope of control (by name) to be delegates. If any one of the selected delegates has also delegated his work items, then your future work item requests will be delegated to that delegate’s delegates.
Select one or more users in the Users Selected area. Alternatively, click Add from Search to open the search feature and search for users. Click Add to add a found user to the list. To remove a delegate from the list, select it, and then click Remove.
My Manager. Select to delegate work items to your manager (if assigned).
DelegateWorkItemRule. Select a rule that returns a list of Waveset user names to which you can delegate the selected work item type.
Start Date. Select the date on which delegation of the work item should start. By default, the day selected begins at 12:01 a.m.
End Date. Select the date on which delegation of the work item should end. By default, the day selected ends at 11:59 p.m.
You can select the same start and end dates to delegate work items for a single day.
Click OK to save selections and return to the list of work items awaiting approval.
After setting up delegation, any work items created during the effective delegation period are added to the delegate’s list. If you end a delegation or the delegation time period expires, then the delegated work items are returned to your list. This may result in duplicate work items on your list. However, when you approve or reject one, then the duplicate will be automatically removed from your list.
Waveset works as follows when a user is deleted that owns any pending work items:
If the pending work items were delegated and the delegator has not been deleted, the pending work items will be returned to the delegator.
If the pending work items were not delegated, or if the pending work items were delegated and the delegator has been deleted, the delete attempt will fail until the user’s pending work items have either been resolved or forwarded to another user.
End one or more delegations from the Current Delegations page.
In the Administrator interface, click Work Items in the main menu.
Click Delegate My Work Items in the secondary menu.
The Current Delegations page opens.
Select one or more delegations to end, and then click End.
Waveset removes the selected delegation configurations, and returns any delegated work items of the type selected to your list of pending work items.
When a user is added to the Waveset system, administrators who are assigned as approvers for new accounts must validate account creation.
Waveset supports three categories of approval:
Organization. Approval is needed for the user account to be added to the organization.
Role. Approval is needed for the user account to be assigned to a role.
Resource. Approval is needed for the user account to be given access to a resource.
In addition, if change-approvals are enabled, and changes are made to a role, a change-approval work item is sent to designated role owners.
Waveset supports change-approvals by Role Definition. If an administrator changes a role definition, change-approval is needed from a designated role owner. A role owner must approve the work item in order for the change to be made.
You can configure Waveset for digitally signed approvals. For instructions see Configuring Digitally Signed Approvals and Actions.
Administrators who are new to Waveset sometimes confuse the concept of approvals with the similar sounding concept of attestation. While the names sound similar, approvals and attestation take place in different contexts.
Approvals are concerned with validating new user accounts. When a user is added to Waveset, one or more approvals may be required to validate that the new account is authorized.
Attestations are concerned with verifying that existing users have only appropriate privileges on appropriate resources. As part of a Periodic Access Review process, an Waveset user (the attestor) may be called upon to certify that another user’s account details (that is, the user’s assigned resources) are valid and correct. This process is known as attestation.
Setting up account approvers for organization, role, and resource approvals is optional, but recommended. For each category in which approvers are set up, at least one approval is required for account creation. If one approver rejects a request for approval, the account is not created.
You can assign more than one approver to each category. Because only one approval within a category is needed, you can set up multiple approvers to help ensure workflow is not delayed or halted. If one approver is unavailable, others are available to handle requests. Approval applies only to account creation. By default, account updates and deletions do not require approval. You can, however, customize this process to require it.
You can customize workflows by using the Identity Manager IDE to change the flow of approvals, capture account deletions, and capture updates.
For information about the Identity Manager IDE, go to https://identitymanager.dev.java.net. For information about workflows, and an illustrated example of altering the approval workflow, see Chapter 1, Workflow, in Oracle Waveset 8.1.1 Deployment Reference.
Waveset Approvers can either approve or reject an approval request.
Administrators can view and manage pending approvals from the Work Items area of the Waveset interface. From the Work Items page, click My Work Items to view pending approvals. Click the Approvals tab to manage approvals.
To approve a work item using a digital signature, you must first set up the digital signature as described in Configuring Digitally Signed Approvals and Actions.
From the Waveset Administrator interface, select Work Items.
Click the Approvals tab.
Select one or more approvals from the list.
Enter comments for the approval, and then click Approve.
Waveset prompts you and asks whether to trust the applet.
Click Always.
Waveset displays a dated summary of the approval.
Enter or click Browse to locate the keystore location. (This location is set during the signed-approval configuration, as described in Step 10m of the To Enable Server-Side Configuration for Signed Approvals Using PKCS12 procedure. )
Enter the keystore password (this password is set during the signed-approval configuration, as described in Step 10l of the procedure To Enable Server-Side Configuration for Signed Approvals Using PKCS12).
Click Sign to approve the request.
After signing an approval, subsequent approval actions require only that you enter the keystore password and then click Sign. (Waveset remembers the keystore location from the previous approval.)
Use the following information and procedures to set up digital signing. You can digitally sign:
Approvals (including change-approvals)
Access review actions
Remediations for compliance violations
The topics discussed in this section explain the server-side and client-side configuration required to add the certificate and CRL to Waveset for signed approvals.
Open the system configuration object for editing and set security.nonrepudiation.signedApprovals=true
For instructions on editing the system configuration object, see Editing Waveset Configuration Objects.
If you are using PKCS11 you must also set security.nonrepudiation.defaultKeystoreType=PKCS11
If you are using a custom PKCS11 Key provider, you must also set security.nonrepudiation.defaultPKCS11KeyProvider=your provider name
Please refer to the following items in the REF kit for more information on when you need to need to write a custom provider:
com.sun.idm.ui.web.applet.transactionsigner.DefaultPKCS11KeyProvider (Javadoc) REF/transactionsigner/SamplePKCS11KeyProvider |
The REF (Resource Extension Facility) kit is provided in the /REF directory on your product CD or with your install image.
Add your certificate authority's (CA) certificates as trusted certificates. To do this, you must first obtain a copy of the certificates.
For example, if you are using a Microsoft CA, follow steps similar to these:
Add the certificate to Waveset as a trusted certificate:
From the Administrator interface, select Security, and then select Certificates. Waveset displays the Certificates page.
In the Trusted CA Certificates area, click Add. Waveset displays the Import Certificate page.
Browse to and then select the trusted certificate, and then click Import.
The certificate now displays in the list of trusted certificates.
Add your CA’s certificate revocation list (CRL):
In the CRLs area of the Certificates page, click Add.
Enter the URL for the CA’s CRL.
The certificate revocation list (CRL) is a list of certificate serial numbers that have been revoked or are not valid.
The URL for the CA’s CRL may be http or LDAP.
Each CA has a different URL where CRLs are distributed; you can determine this by browsing the CA certificate’s CRL Distribution Points extension.
Click Test Connection to verify the URL.
Click Save.
Sign applets/ts2.jar using jarsigner.
Refer to http://download.oracle.com/docs/cd/E17476_01/javase/1.5.0/docs/tooldocs/windows/jarsigner.html for more information. The ts2.jar file provided with Waveset is signed using a self-signed certificate, and should not be used for production systems. In production, this file should be re-signed using a code-signing certificate issued by your trusted CA.
The following configuration information is for signed approvals using PKCS12. Obtain a certificate and private key, and then export them to a PKCS#12 keystore. For example, if using a Microsoft CA, you would follow steps similar to these:
Waveset now requires at least JRE 1.5.
Using Internet Explorer, browse to http://IPAddress/certsrv and log in with administrative privileges.
Select Request a certificate, and then click Next.
Select Advanced request, and then click Next.
Click Next.
Select User for Certificate Template.
Select these options:
Click Submit, and then click OK.
Click Install this certificate.
Select Run -> mmc to launch mmc.
Add the Certificate snap-in:
Select Console -> Add/Remove Snap-in.
Click Add.
Select Computer account.
Click Next, and then click Finish.
Click Close.
Click OK.
Go to Certificates -> Personal -> Certificates.
Right-click Administrator All Tasks -> Export.
Click Next.
Click Next to confirm exporting the private key.
Click Next.
Provide a password, and then click Next.
File CertificateLocation.
Click Next, and then click Finish. Click OK to confirm.
Note the information that you use in step 10l (password) and 10m (certificate location) of the client-side configuration. You will need this information to sign approvals.
If you are using PKCS11 for signed approvals
Refer to the following resources in the REF kit for configuration information:
com.sun.idm.ui.web.applet.transactionsigner.DefaultPKCS11KeyProvider (Javadoc) REF/transactionsigner/SamplePKCS11KeyProvider |
The REF (Resource Extension Facility) kit is provided in the /REF directory on your product CD or with your install image.
This section describes the procedure for viewing transaction signatures in an Waveset AuditLog report.
From the Waveset Administrator interface, select Reports.
On the Run Reports page, select AuditLog Report from the New list of options.
In the Report Title field, enter a title (for example, Approvals).
In the Organizations selection area, select all organizations.
Select the Actions option, and then select Approve.
Click Save to save the report and return to the Run Reports page.
Click Run to run the Approvals report.
Click the details link to see transaction signature information.
Transaction signature information can include the following:
Issuer
Subject
Certificate serial number
Message signed
Signature
Signature algorithm
Waveset allows you to add XMLDSIG-format signed approvals, including an RFC 3161-compliant digital timestamp, to the Waveset approval process. When you configure Waveset to use XMLDSIG signed approvals, no changes are visible to approvers unless they view the approval in the audit log. Only the format of the signed approval that is stored in the audit log record is changed.
As with previous signed approvals in Oracle Waveset, an applet is launched on the client machine and the approver is presented with the approval information for signing. They then choose a keystore and a key with which to sign the approval.
After the approver signs the approval, an XMLDSIG document containing the approval data is created. This document is returned to the server which validates the XMLDSIG signed document. If successful, and if RFC 3161 digital timestamps have been configured, a digital timestamp is also generated for this document. The timestamp retrieved from the timestamp authority (TSA) is checked for errors and its certificates are validated. Finally, if successful, Oracle Waveset generates an audit log record that includes the XMLDSIG-format signed approval object in the XML blob column.
The format for an XMLDSIG-format approval object is as follows:
<XMLSignedData signedContent="...base64 transaction text ..."> <XMLSignature> <TSATimestamp> ...The base64 encoded PKCS7 timestamp token returned by the TSA... </TSATimestamp <Signature> <SignedInfo>...XMLDSIG stuff...</SignedInfo> <SignatureValue>...base64 signature value</SignatureValue> <KeyInfo>...cert info for signer</KeyInfo> </Signature> </XMLSignature> </XMLSignedData>
where:
The base64 approval data consists of the actual approval data text that is presented to the approver in the applet, encoded in base64 format.
The <TSATimestamp> element contains the base64 encoded PKCS7 timestamp response from the Timestamp Authority (TSA).
The entire <Signature> comprises the XMLDSIG signature data.
This XMLDSIG document that is stored in the XML column of the audit log approval record.
The installation and setup requirements for using XMLDSIG signed approvals are the same as those described in To Enable Server-Side Configuration for Signed Approvals, with one additional step. You must sign the xmlsec-1.4.2.jar file in addition to signing the ts2.jar file.
You can use system configuration attributes to:
Choose the SignedData format or the XMLSignedData format. Note that you can configure only one format at a time, although administrators can change this setting as needed.
Include a digital timestamp retrieved from a configured RFC 3161 Timestamp Authority (TSA).
Specify a URL, in HTTP only, from which to fetch this timestamp.
To edit these attributes, use the Waveset debug pages to edit the system configuration object. These attributes are all located under security.nonrepudiation, along with other signed approval attributes.
The XMLDSIG attributes include:
security.nonrepudiation.useXmlDigitalSignatures is a boolean value that enables XMLDSIG signatures.
security.nonrepudiation.timestampXmlDigitalSignatures is a boolean value that includes RFC 3161 digital timestamps in XMLDSIG signatures.
security.nonrepudiation.timestampServerURL is a string value where the URL points to the HTTP-based TSA from which to fetch timestamps.
You must first set the existing useSignedApprovals attribute to true for any of the preceding attributes to have an effect.
Waveset does not support multiple signatures on one approval or signed approvals for more general provisioning requests.