| Oracle® Fusion Middleware Administrator's Guide for Oracle WebCenter Interaction 10g Release 3 (10.3.0.1) Part Number E14107-02 |
|
|
View PDF |
| Oracle® Fusion Middleware Administrator's Guide for Oracle WebCenter Interaction 10g Release 3 (10.3.0.1) Part Number E14107-02 |
|
|
View PDF |
This chapter describes the portal conventions for user and group management and provides the steps you take to implement managed access to portal objects.
Before you begin the task of managing portal groups and users, develop a plan to manage the administrative roles, groups, and users for your enterprise portal. For detailed information on developing a plan, refer to the Deployment Guide for Oracle WebCenter Interaction.
Portal users enable you to authenticate the people who access your portal and assign appropriate security for the documents and objects in your portal. Users can be imported from external user repositories, created through the portal, created through invitations, self-registered, or just guests (unauthenticated users).
Each user is assigned a default profile at creation. Default profiles define initial My Account settings, such as language, time zone, and portal interface type; the name and number of My Pages; and the layout of the portlets on those My Pages. Default profiles provide an initial view of the portal, which users can then change to fit their needs.
Note:
Portlet preferences, group memberships, and community memberships are not inherited by users created from default profiles.Default profiles are defined through special users, created in the Default Profiles folder (accessed through the Default Profiles Utility). These special users cannot log in to the portal. They are solely used to assign settings to new users.
You can use authentication sources to import users that are already defined in your enterprise in existing user repositories, such as Active Directory or LDAP servers. After users are imported, you can authenticate them with the credentials from those user repositories. You can also import user information (such as name, address, or phone number), which can then be used to populate user profiles or can be passed to content crawlers, remote portlets, or federated searches as user information.
You can invite users to your portal through invitations, making it easy for them to create their own accounts and letting you customize their initial portal experiences with content that is of particular interest to them.
Users can create their own accounts through your portal by clicking Create an account on the login page. These users are stored in the Default Experience Definition portal folder and are included in the WCI Authentication Source. They are automatically given security privileges based on the “Default Profile” created at installation. Based on this security, users can personalize their views of the portal with My Pages, portlets, and community memberships, and can view portal content.
Note:
Your system administrator can disable the Create an account functionality.The portal lets you create multiple guest users. This is useful when you want to have different user experiences for different sets of unauthenticated users. You can accomplish this by creating a guest user for each group of unauthenticated users that you want to see a different user experience. You then associate each guest user with a different experience definition, customize the My Page for each guest user, and use experience rules to direct the guest users to the appropriate experience definition.
For example, you could create one guest user for employees that have not yet logged in to the portal and one for customers visiting your portal. The My Page for the employee guest user would include the login portlet so employees can log in. The My Page for customers might include information about your company, such as contact numbers and descriptions of your products or services. You would create two experience definitions, associating one guest user with each. Then you would create two experience rules that would direct users to the appropriate experience definition based on the URL they use to access your portal.
When new authenticated users are created in the portal, the following settings are based on default profiles: initial My Account settings, name and number of My Pages, and layout of the portlets on those My Pages.
To create a default profile you need the following rights:
Access Administration activity right
Access Utilities activity right
Click Administration.
In the Select Utility list, click Default Profiles.
The Default Profiles folder opens.
In the Create Object list, click User.
In the Login Name box, type a name for this default profile.
Users created from this default profile will have their own user names and passwords.
Note:
Do not select This is a guest account. Instead, to create a guest user, go to a different administrative folder, create a user there, and make that user a guest.
Do not add this user to any groups. Group memberships are not inherited by users created from default profiles. You set group membership through invitations or authentication sources.
After you have created a default profile, edit its layout.
When new authenticated users are created in the portal, the following settings are based on default profiles: initial My Account settings, name and number of My Pages, and layout of the portlets on those My Pages.
To customize a default profile experience you need the following rights:
Access Administration activity right
Access Utilities activity right
If you are not already in the Default Profiles folder, click Administration, and, in the Select Utility list, click Default Profiles.
Select the profile that you want to customize.
Click Edit Profile Layout.
Specify My Account settings, create and delete My Pages, and change the layout of the My Pages.
Note:
Portlet preferences are not inherited by users created from the default profile. Users set their own preferences.
Community membership and access to documents and objects are granted through group membership.
After you have customized the default profile, use invitations and authentication sources to assign the profile to new portal users and to assign group membership.
You lock user accounts to disable access to the portal. You can configure automatic locking based on repeated failed login attempts, or you can lock user accounts any time with the User Editor.
You can automatically lock user accounts based on failed login attempts.
Click Administration.
In the Select Utility list, click Portal Settings.
On the User Settings Manager page, enable account locking and specify how long failed logins are tracked, the total number of failed logins required before an account will be locked, and the number of minutes for which automatically locked accounts remain locked.
Your individual security needs will determine what settings to use for automatic account locking. For example, to meet a strength of password function rating of SOF-basic as defined in the Common Criteria for Information Technology Security Evaluation, Version 2.3, August 2005 (found at http://niap.bahialab.com/cc-scheme/cc_docs/), you might set the following values:
Minutes to track failed Logins: 60 minutes or more
Number of failed Login attempts allowed: 5 or fewer
Minutes to keep user account locked: 60 minutes or more
You can manually lock user accounts through the User Editor.
Click Administration.
Navigate to the user whose account you want to lock and click the user name.
Select Disable Login.
The lock on accounts that are locked automatically will eventually expire, but you can remove account locks with the Release Disabled Logins utility or the User Editor.
You unlock user accounts differently depending on how the account was locked:
Admin Lock: A portal administrator locked the user account.
Automatic Lock: If the user repeatedly types the wrong user name or password when logging into the portal, the portal locks the account. The number of login attempts allowed before the user is locked out is determined in the Portal Settings utility.
Note:
Locks on accounts that are locked automatically eventually expire.Agent Lock: A user account might be locked if it is not found in the external authentication server during a synchronization job. This lock might be unexpected if the synchronization job did not find the user because the job failed.
Note:
Users can remove the lock by specifying the correct credentials the next time they log in.To remove an Admin Lock or an Automatic Lock with the Release Disabled Logins Utility:
Click Administration.
In the Select Utilities list, click Release Disabled Logins.
To remove an Admin Lock or an Automatic Lock with the User Editor:
Click Administration.
Navigate to the user whose account you want to unlock and click the user name.
Clear the check box next to Disable Login.
To remove an Agent Locks for all affected users:
Click Administration.
Navigate to the authentication source and click its name.
Click Fully Synchronized Groups page.
Click Re-Enable Users.
Unlocking these accounts may take a few minutes.
You should delete users that should no longer have access to your portal.
To delete a user you must have the following rights and privileges:
Access Administration activity right
Admin access to the user
To delete a user:
Click Administration.
Navigate to the user.
Select the user you want to delete and click the Delete icon.
To delete a user whose account is locked:
Click Administration.
In the Select Utilities list, click Release Disabled Logins.
Select the user you want to delete and click the delete icon.
Groups are created in the portal either by adding them individually as portal objects, or by synchronizing with authentication sources (user repositories such as LDAP or Active Directory).
Membership to a group is determined in two ways:
Members are explicitly defined as specific users and/or other groups on the Group Memberships page.
Members are dynamically determined based on rules you set up on the Dynamic Membership Rules page.
You might want to have users automatically added to or removed from groups based on properties in their user profiles or other group membership. This is called dynamic group membership. For example, you might want to give users access to a community based on their location, title, department, or any other property in their profile. If you have a community for all the branches in Texas, you could set up a rule that states that all employees in Texas are part of the group. If an employee moves to Arizona, and the “State” property in her profile changes, the employee no longer satisfies this rule.
You can create groups inside a community without affecting portal groups. You create community groups so that you can easily assign responsibilities to community members. For example, you might have a group that is responsible for maintaining schedules in the community.
Community groups are available only within the community. However, you can make a community group available outside of the community by moving the group to a non-community administrative folder.
A role is not a portal object; it is an association between a group and the activity rights required to perform a job function. For example, the Knowledge Directory administrator role is not an object you define; it relates to administrative responsibilities for those who manage content in the Knowledge Directory.
Before you create portal groups for the purpose of assigning roles, you should familiarize yourself with the definition and scope of the administrative tasks you plan to delegate and the activity rights needed to complete those administrative tasks. Some users will handle many tasks, but those tasks might actually encompass several roles. Before creating a role to cover all these tasks, consider if there are situations where the tasks will be broken down into smaller roles. You can easily assign more than one role to a user.
The following groups are created in the Portal Resources folder when you install the portal:
Administrators Group: This group provides full access to everything in the portal: all objects, all utilities, and all portal activities.
Everyone: This group includes all portal users, whether created manually through the administration menu, imported from authentication sources, created through acceptance of an invitation, or created through the Create an Account page.
A role is not a portal object; it is an association between a group and the activity rights required to perform a job function.
The following table describes the activity rights that are defined by default during installation and provides an example map between activity rights and administrative roles. In the example, the role called Content Administrator provides the activity rights required to populate the portal with document records crawled from remote content sources; a separate role called Knowledge Directory Administrator provides the activity rights required to create Knowledge Directory structure. Although some users might fill both roles, others might not. By creating two separate roles, you can assign the roles separately or together.
| Role | Activity Rights Needed |
|---|---|
| Portal Administrator: Manages all areas of the portal | All activity rights |
| Content Administrator: Populates the portal with document records crawled from remote content sources | Access Administration, Access Utilities, Create Admin Folders, Create Content Types, Create Content Crawlers, Create Content Sources, and Create Jobs |
| Knowledge Directory Administrator: Creates Knowledge Directory structure and approves content | Access Smart Sort, Access Unclassified Documents, Access Utilities, Advanced Document Submission, Create Filters, Create Folders, Edit Knowledge Directory, and Self-Selected Experts |
Groups are sets of users, sets of other groups, or both. Groups enable you to more easily control security because you assign each group different activity rights and access privileges.
To create a group you must have the following rights and privileges:
Access Administration activity right
Create Groups activity right
At least Edit access to the parent folder (the folder that will store the group)
At least Select access to any groups to which you want to add this group
At least Select access to any users you want to add to the group
Click Administration.
Open the folder in which you want to store the group.
In the Create Object list, click Group.
Under Parent Group Memberships, specify the groups to which this group should be a member:
To make this group a member of another group, click Add Group, in the Select Groups dialog box, select the groups to which you want to add this group, and click OK.
To remove a parent group, select it and click the Remove icon.
To select or clear all of the group boxes, select or clear the box to the left of Members.
To toggle the order in which the groups are sorted, click Members.
Under Group Members, specify the members of this group:
To add members to this group, click Add User/Group, in the Select Members dialog box, select the groups and users you want to add to this group, and click OK.
To remove a member, select it and click the Remove icon.
To remove a member, select it and click the Remove icon.
To select or clear all of the member boxes, select or clear the box to the left of Members.
To toggle the order in which the members are sorted, click Members.
If you want users and groups to be added to this group based on user profile properties or group membership, set dynamic membership rules. If you want members of this group to be able to access administration, create objects, or perform other activities that require special rights, assign activity rights to the group.
You might want to have users automatically added to or removed from groups based on properties in their user profiles or other group membership. This is called dynamic group membership. For example, you might want to give users access to a community based on their location, title, department, or any other property in their profile. If you have a community for all the branches in Texas, you could set up a rule that states that all employees in Texas are part of the group. If an employee moves to Arizona, and the “State” property in her profile changes, the employee no longer satisfies this rule.
Dynamic membership rules are made up of statements that define what must or must not be true to include a user in the group. The statements are collected together in groupings. The grouping defines whether the statements are evaluated with an AND operator (all statements are true) or an OR operator (any statement is true). If some statements should be evaluated with an AND operator and some should be evaluated with an OR operator, you can create separate groupings for the statements. You can also create subgroupings or nested groupings, where one grouping is contained within another grouping. The statements in the lowest-level grouping are evaluated first to define a set of users. Then the statements in the next highest grouping are applied to that set of users to further filter the set of users. The filtering continues up the levels of groupings until all the groupings of statements are evaluated.
Open the Group Editor by creating a new group or editing an existing one.
Click the Dynamic Membership Rules page.
Select the operator for the grouping of statements you are about to create:
If a user should be added to the group only when all statements in the grouping are true, select AND.
If a user should be added to the group when any statement in grouping is true, select OR.
Note:
The operator you select for a grouping applies to all its statements and subgroupings directly under it.Define each statement in the grouping:
Click Add Statement.
In the first list, select a property.
This list includes the properties included in the user profile and Member Of, which enables you to select a group whose members you want to include or exclude.
In the second list, select an operator:
If you selected a user profile property, you can select Contains or Contains No Value.
If you selected Member Of, you can select includes or excludes.
If you selected Contains as the operator, in the text box, enter a value for the property.
You can use wildcards.
If you selected Member Of, select the groups whose members you want to include or exclude. Click the Edit icon, in the Group Chooser dialog box, select a group, and click OK.
Note:
The Group Chooser dialog box displays only statically defined groups.To add more statements, repeat these steps.
To remove the last statement in a grouping, select the grouping and click Remove Statement.
If necessary, add more groupings:
To add another grouping, select the grouping to which you want to add a subgrouping and click Add Grouping. Then define the statements for that grouping.
Note:
You cannot add a grouping at the same level as Grouping 1.To remove a grouping, select the grouping, and click Remove Grouping.
Note:
Any groupings and statements in that grouping will also be removed.
You cannot remove the top level Grouping 1.
Click Preview Members to see the dynamic members resulting from the rules you defined.
Only 1000 members will be displayed.
The dynamic members are updated for this group when you click Finish.
The next time you open this group editor, dynamic members are displayed on the Group Memberships page.
Dynamic memberships are updated for all groups as part of the Dynamic Membership Update Agent job (located in the Intrinsic Operations folder). When user profile data changes, the resulting dynamic group membership changes are updated as part of this job.
Activity rights determine which portal objects a user can create and which portal utilities a user can execute to create or modify portal objects.
It is not necessary to grant a user the right to create a type of object for that user to manage an object of that type. Management of an object is based solely on a user's access privilege to that object.
If the Group Editor is not already open, open it now and display the Activity Rights page.
Under Activity Rights, click Add Activity Rights.
The Select Activity Rights dialog box opens.
Select the activity rights you want to grant to the group and click OK.
For example, if you select Create Jobs, the members of the group will be able to create jobs in the portal.
To remove activity rights, select the activity right that you want to remove and click the Remove icon.
Under Inherited Activity Rights you see any activity rights granted to the parent groups of this group.
Authentication sources enable you to import users, groups, and group memberships that are already defined in your enterprise in existing user repositories, such as Active Directory or LDAP servers. After users are imported, you can authenticate them with the credentials from those user repositories.
An authentication provider is a piece of software that tells the portal how to use the information in the external user repository. Oracle provides authentication providers as part of the Oracle WebCenter Interaction Identity Services. The Oracle WebCenter Interaction Identity Service for LDAP is used to import and authenticate users and group from LDAP servers. The Oracle WebCenter Interaction Identity Service for Microsoft Active Directory is used to import and authenticate users and groups from Active Directory servers. If your users and groups reside in a custom system, such as a custom database, you can import and authenticate them by writing your own authentication provider using the IDK.
Note:
Your portal administrator must install the authentication provider before you can create the associated authentication web service. For information on obtaining authentication providers, refer to the Oracle Support site at http://www.oracle.com/support/index.html. For information on installing authentication providers, refer to the Installation Guide for Oracle WebCenter Interaction (available on the Oracle Technology Network at http://www.oracle.com/technology/documentation/bea.html) or the documentation that comes with your authentication provider, or contact your portal administrator.
To learn about developing your own authentication provider, to the Oracle Fusion Middleware Web Service Developer's Guide for Oracle WebCenter Interaction, which is located on the Oracle Technology Network at http://www.oracle.com/technology/documentation/bea.html.
Authentication web services enable you to specify general settings for your external user repository, leaving the more detailed settings (like domain specification) to be set in the associated remote authentication sources. This allows you to create different authentication sources to import each domain without having to repeatedly specify all the settings.
Authentication sources can import users and/or groups, authenticate imported users, or both import and authenticate. Your security needs determine how many authentication sources to create and what functionality they need. You might be able to create just one authentication source that imports and authenticates all users and groups, but here are a couple examples of when that would not suffice:
If you want to use single sign-on (SSO), create a synchronization-only authentication source.
If you want to distinguish users and groups from different domains, create separate synchronization-only authentication sources for each domain, and create an authentication-only authentication source to authenticate users from all domains (assuming they are from the same user repository).
This enables you to store users and groups imported from different domains in different portal folders or to create separate users or groups with the same name but from different domains.
If you are importing users and groups into the portal, you run a job for the initial import and then continue to run the job periodically to keep the users and groups in the portal synchronized with those in the source user repository.
Note:
When you run the job to import users and groups, the portal also creates a group that includes all users imported through the authentication source. This group is named after the authentication source; for example, if your authentication source is called mySource, the group would be called Everyone in mySource.When you use authentication sources to authenticate portal users, the user credentials are left in the external repository; they are not stored in the portal database. When someone attempts to log in to your portal through an imported user account, the portal confirms the password with the external repository. This means that the user's portal password always matches the password in the external repository. For example, if a user with a portal account imported from Active Directory changes the Active Directory password, the user can immediately log in to the portal with that password. If the user is already logged in to the portal, the user must log in again with the new password, because the portal will no longer be able to recognize the old password.
The WCI Authentication Source is automatically created upon installation. It is the authentication source used for users stored in the portal database (users created upon install, users created manually through the portal, and self-registered users). This authentication source cannot be modified or deleted.
Before you create an authentication web service, you must:
Install the authentication provider on the computer that hosts the portal or on another computer
Create a remote server pointing to the computer that hosts the authentication provider (optional, but recommended)
To create an authentication web service you must have the following rights and privileges:
Access Administration activity right
Create Web Service Infrastructure activity right
At least Edit access to the parent folder (the folder that will store the authentication web service)
At least Select access to the remote server that the authentication web service will use
Click Administration.
Open the folder in which you want to store the authentication web service.
In the Create Object list, click Web Service — Authentication.
The Authentication Web Service Editor opens.
On the Main Settings page, complete the following tasks:
Associate a remote server for the web service
Specify the path to the authentication provider
Specify authentication time-out setting for the web service
Specify the path to the synchronization provider
Specify synchronization time-out setting for the web service
Enable the web service
Click the HTTP Configuration page and complete the following task:
Specify whether the content should be gatewayed
Click the Advanced Settings page and complete the following task:
Specify how information from this web service is encoded
Click the Authentication Settings page and complete the following task:
Specify what authentication information, if any, you want this web service to pass to its associated authentication sources
Click the Debug Settings page and complete the following task:
Enable desired error tracing
Click the Properties and Names page and complete the following tasks:
Naming and Describing an Object
You can instead enter a name and description when you save this authentication web service.
Localizing the Name and Description for an Object (optional)
Managing Object Properties (optional)
The default security for this authentication web service is based on the security of the parent folder. You can change the security when you save this authentication web service (on the Security tab page in the Save As dialog box), or by editing this authentication web service (on the Security page of the Authentication Web Service Editor).
Portal administrators with at least Select access to this authentication web service can create authentication sources based on the web service.
Users imported through an authentication source can automatically be granted access to the content imported by some remote content crawlers. The Global ACL Sync Map shows these content crawlers how to import source document security.
To access the Global ACL Sync Map you must be a member of the Administrators group.
For an example of how importing security works for users imported through an authentication source, see Example of Importing Security.
You can create a remote authentication source to import and authenticate users and groups from external user repositories.
Before you create an authentication source, you must:
Install the authentication provider on the computer that hosts the portal or on another computer.
Create a remote server that points to the computer that hosts the authentication provider.
Create an authentication web service on which to base the authentication source.
Create and configure the default profiles you want to apply to imported users.
Create the folders in which you want to store the imported users.
To create an authentication source you must have the following rights and privileges:
Access Administration activity right
Create Authentication Sources activity right
At least Edit access to the parent folder (the folder that will store the authentication source)
At least Select access to the authentication web service on which this authentication source will be based
At least Select access to the default profiles you want to apply to imported users
At least Select access to the folders in which you want to store the imported users
Click Administration.
Open the folder in which you want to store the authentication source.
In the Create Object list, click Authentication Source - Remote.
The Choose Web Service dialog box opens.
Select the web service that provides the basic settings for your authentication source and click OK.
The Remote Authentication Source Editor opens.
On the Main Settings page, complete the following tasks:
Click the Synchronization page and complete the following tasks:
Click the Fully Synchronized Groups page and complete the following task:
Click the Set Job page and complete the following task:
Click the Properties and Names page and complete the following tasks:
Naming and Describing an Object
Note:
The authentication source name appears in lists of objects from which users will sometimes choose; therefore, the name should clearly convey the purpose of this authentication source.You can instead enter a name and description when you save this authentication source.
Localizing the Name and Description for an Object (optional)
Managing Object Properties (optional)
The default security for this authentication source is based on the security of the parent folder. You can change the security when you save this authentication source (on the Security tab page in the Save As dialog box), or by editing this authentication source (on the Security page of the Authentication Source Editor).
Run the job you associated with this authentication source.
If you are importing only partial users or groups or are applying different default profiles to each group of users, after the associated job runs once, return to the Authentication Source Editor and perform any necessary additional tasks.
You can import users with an authentication source and have them authenticated through an associated authentication partner.
Before you create an authentication source, you must:
Install the authentication provider on the computer that hosts the portal or on another computer.
Create a remote server that points to the computer that hosts the authentication provider.
Create an authentication web service on which to base the authentication source.
Create and configure the default profiles you want to apply to imported users.
Create the folders in which you want to store the imported users.
Create an authentication source that will authenticate users imported with this authentication source.
To create an authentication source you must have the following rights and privileges:
Access Administration activity right
Create Authentication Sources activity right
At least Edit access to the parent folder (the folder that will store the authentication source)
At least Select access to the authentication web service on which this authentication source will be based
At least Select access to the authentication source that will authenticate users imported with this authentication source.
Click Administration.
Open the folder in which you want to store the authentication source.
In the Create Object list, click Authentication Source - Remote.
The Choose Web Service dialog box opens.
Select the web service that provides the basic settings for your authentication source and click OK.
The Remote Authentication Source Editor opens.
On the Main Settings page, complete the following tasks:
Click the Synchronization page and complete the following tasks:
Click the Fully Synchronized Groups page and complete the following task:
Click the Set Job page and complete the following task:
Click the Properties and Names page and complete the following tasks:
Naming and Describing an Object
Note:
The authentication source name appears in lists of objects from which users will sometimes choose; therefore, the name should clearly convey the purpose of this authentication source.You can instead enter a name and description when you save this authentication source.
Localizing the Name and Description for an Object (optional)
Managing Object Properties (optional)
The default security for this authentication source is based on the security of the parent folder. You can change the security when you save this authentication source (on the Security tab page in the Save As dialog box), or by editing this authentication source (on the Security page of the Authentication Source Editor).
Run the job you associated with this authentication source.
If you are importing only partial users or groups or are applying different default profiles to each group of users, after the associated job runs once, return to the Authentication Source Editor and perform any necessary additional tasks.
If you have more than one authentication source importing users from the same user repository, create an authentication-only authentication source to authenticate your users.
Before you create an authentication source, you must:
Install the authentication provider on the computer that hosts the portal or on another computer.
Create a remote server that points to the computer that hosts the authentication provider.
Create an authentication web service on which to base the authentication source.
To create an authentication source you must have the following rights and privileges:
Access Administration activity right
Create Authentication Sources activity right
At least Edit access to the parent folder (the folder that will store the authentication source)
At least Select access to the authentication web service on which this authentication source will be based
Click Administration.
Open the folder in which you want to store the authentication source.
In the Create Object list, click Authentication Source - Remote.
The Choose Web Service dialog box opens.
Select the web service that provides the basic settings for your authentication source and click OK.
The Remote Authentication Source Editor opens.
On the Main Settings page, complete the following task:
Click the Synchronization page and, under General Info, select Authentication Only.
Click the Properties and Names page and complete the following tasks:
Naming and Describing an Object
Note:
The authentication source name appears in lists of objects from which users will sometimes choose; therefore, the name should clearly convey the purpose of this authentication source.You can instead enter a name and description when you save this authentication source.
Localizing the Name and Description for an Object (optional)
Managing Object Properties (optional)
The default security for this authentication source is based on the security of the parent folder. You can change the security when you save this authentication source (on the Security tab page in the Save As dialog box), or by editing this authentication source (on the Security page of the Authentication Source Editor).
Add this authentication source as the authentication partner for a synchronization-only authentication source.
You can import users with an authentication source and have them authenticated transparently through single sign-on (SSO).
Before you create an SSO authentication source, you must:
Install the authentication provider on the computer that hosts the portal or on another computer.
Create a remote server that points to the computer that hosts the authentication provider.
Create an authentication web service on which to base the authentication source.
Create and configure the default profiles you want to apply to imported users.
Create the folders in which you want to store the imported users.
To create an SSO authentication source you must have the following rights and privileges:
Access Administration activity right
Create Authentication Sources activity right
At least Edit access to the parent folder (the folder that will store the authentication source)
At least Select access to the authentication web service on which this authentication source will be based
Click Administration.
Open the folder in which you want to store the authentication source.
In the Create Object list, click Authentication Source - Remote.
The Choose Web Service dialog box opens.
Select the web service that provides the basic settings for your authentication source and click OK.
The Remote Authentication Source Editor opens.
On the Main Settings page, complete the following tasks:
Click the Synchronization page and complete the following tasks:
Under General Info, select Synchronization with Authentication Partner.
In the Authentication Partners list, select SSO Authentication Source.
Click the Fully Synchronized Groups page and complete the following task:
Click the Set Job page and complete the following task:
Click the Properties and Names page and complete the following tasks:
Naming and Describing an Object
Note:
The authentication source name appears in lists of objects from which users will sometimes choose; therefore, the name should clearly convey the purpose of this authentication source.You can instead enter a name and description when you save this authentication source.
Localizing the Name and Description for an Object (optional)
Managing Object Properties (optional)
Run the job you associated with this authentication source.
If you are importing only partial users or groups or are applying different default profiles to each group of users, after the associated job runs once, return to the Authentication Source Editor and perform any necessary additional tasks.If you have not already done so, you must modify the portal configuration to enable SSO.
On the Main Settings page of the Authentication Source Editor, you set the prefix you want to add to user and group names to distinguish the domain from which they were imported. For example, if you enter myDomain, each user name and each group name will be prefixed by the string myDomain; myUser becomes myDomain/myUser and myGroup becomes myDomain/myGroup.
If the Authentication Source Editor is not already open, open it now by creating an authentication source.
Note:
You can set the category only during authentication source creation.Under Category, in the Authentication Source Category box, type the prefix you want to add to user and group names to distinguish that they were imported from this domain.
Generally, you can set the category to any value you want, but there are a few important considerations:
Do not include spaces in the prefix.
After you create this authentication source you cannot change the category value.
If you are using Windows Integrated Authentication (WIA) as your single sign-on (SSO) authentication provider, your authentication source category must match the domain name.
You might want the authentication source category to match the domain name if you are going to import security information. Some content crawlers have the ability to import security information with the imported content, making portal security much easier to maintain. For this to work, the users with access to the imported content need to correspond to portal users, as specified in the Global ACL Sync Map. If the authentication source category matches the name of the source domain, this correspondence is automatic.
Multiple authentication sources can use the same category. However, because the prefix is prepended to the user and group names, you need to be certain that the domains involved do not have different users or groups with the same name. That is, if a LizaR user exists on one domain, and a LizaR user exists on another domain, they must be the same user because only one user will be created.
Specify which default profiles to apply to users imported by an authentication source. A default profile includes portlets, portlet preferences, My Pages, and personalization settings. By assigning a default profile to the imported users, you can control what users see when they first log in to your portal. After that, users can further personalize their views of the portal.
You must have at least Select access to the folder in which you want to store imported groups.
If the Authentication Source Editor is not already open, open it now.
To apply the same default profile to all users imported by this authentication source, you can specify the following settings when you create the authentication source:
In the Default Profile drop-down list, select the default profile to apply to the imported users.
Under Target Folder, click Browse to select the folder in which to store the imported users.
If you want to display an experience definition interface to the imported users when they log in, choose a folder to which the experience definition has been applied or apply the experience definition to the chosen folder before you import users.
By default, users imported by this authentication source are stored in the same folder that stores the authentication source.
To apply different default profiles to the users in some groups:
Perform a Partial Users Synchronization to import all the groups.
Return to the Authentication Source Editor.
Click Add Group; then, in the Add Group dialog box, select the groups to which you want to apply different default profiles and click OK.
Note:
To view the members of a group or edit a group, click the group name.For each group, perform the following actions:
In the Default Profile drop-down list, select the default profile to apply to the imported users.
Under Target Folder, click Browse to select the folder in which to store the imported users.
If you want to display an experience definition interface to the imported users when they log in, choose a folder to which the experience definition has been applied or apply the experience definition to the chosen folder before you import users.
By default, users imported by this authentication source are stored in the same folder that stores the authentication source.
Prioritize the default profiles by changing the order of the groups.
If a user is a member of more than one group in this list, the uppermost default profile is applied. If necessary, move groups up or down in the list.
After you have configured all the settings for this authentication source, you must run a job to import the users and groups.
By default, groups imported by an authentication source are stored in the same folder that stores the authentication source, but you can select a different folder if you want.
You must have at least Select access to the folder in which you want to store imported groups.
If the Authentication Source Editor is not already open, open it now.
Under New Groups, click Browse to select the folder in which to store the imported groups.
The Change Folder dialog box opens.
Select the select a folder and click OK.
After you have configured all the settings for this authentication source, you must run a job to import the users and groups.
When you set an authentication source to synchronize users and/or groups from a source user repository, you can specify which users and groups to synchronize.
Note:
When you synchronize users/groups, new users/groups are imported into the portal and deleted users/groups are removed from the portal.If the Authentication Source Editor is not already open, open it now.
Click the Synchronization page.
Specify which users and groups to synchronize.
To import all users and groups from the source domain, select Full Synchronization.
Each time you run the job associated with this authentication source all users and groups will be synchronized with the portal.
To import the users from selected groups, but not all of the users found on the source domain, perform the following steps:
Select Partial Users Synchronization.
Run the job associated with this authentication source.
All of the groups in the source user repository are imported into the portal, but no users are imported.
Return to the Authentication Source Editor and click the Fully Synchronized Groups page.
Select the groups you want to fully synchronize.
Run the job associated with this authentication source again.
Each time you run the job associated with this authentication source all groups are synchronized, but the only users that are synchronized are the ones that are members of the fully synchronized groups.
To import all users, but only selected groups, perform the following steps:
Select Full Synchronization or Partial Users Synchronization.
Run the job associated with this authentication source.
Delete all unwanted groups from the portal.
Return to the Authentication Source Editor and click the Synchronization page.
Select Partial Groups Synchronization.
Run the job associated with this authentication source again.
Each time you run the job associated with this authentication source all users are synchronized, but no new groups are imported. Groups are still removed from the portal if they are deleted from the source user repository.
To import selected users and selected groups, perform the following steps:
Select Partial Users Synchronization.
Run the job associated with this authentication source.
All of the groups on the source domain are imported into the portal, but no users are imported.
Delete all unwanted groups from the portal.
Return to the Authentication Source Editor and click the Fully Synchronized Groups page.
Select the groups from which you want to import users.
Click the Synchronization page.
Select Partial Users and Partial Group Synchronization.
Run the job associated with this authentication source again.
Each time you run the job associated with this authentication source the only users that are synchronized are the ones that are members of the fully synchronized groups, and no new groups are imported. Groups are still removed from the portal if they are deleted from the source user repository.
To import no users or groups, choose No Synchronization.
If users from another authentication source are members of groups from this authentication source or vice versa, select Import user and group memberships from other authentication sources.
In the Import batches of box, type the number of users you want to import at a time.
The default batch setting is 1000 users. Some databases cannot support a batch of 1000; the most common reason is that the database runs out of space in the rollback segment because it attempts to add all 1000 users within one transaction. This situation terminates the transaction, and no users are imported.
Note:
Raising the import batch number can improve the time it takes to synchronize.The Fully Synchronized Groups page of the Authentication Source Editor enables you to choose groups from which you want to import users. The groups that you list on this page are synchronized with the corresponding groups on the source server.
Before you can select groups to fully synchronize, you must import the groups by running the authentication source in Partial Users Synchronization or Partial Users and Partial Group Synchronization mode.
If the Authentication Source Editor is not already open, open it now.
Click the Fully Synchronized Groups page.
Select groups from which to import users:
To add a group, click Add Group; then, in the Add Group dialog box, select the groups you want to add and click OK.
To add every group imported by this authentication source, click Add All Groups.
To delete a group, select the group and click the Delete icon.
To select or clear all of the group boxes, select or clear the box to the left of Group.
To edit a group, click the group name.
The Fully Synchronized Groups page of the Authentication Source Editor enables you to specify what to do with users and groups deleted from the source user repository. By default the portal users are disabled and groups are moved to a folder for future deletion, but you can change this behavior.
If the Authentication Source Editor is not already open, open it now.
Click the Fully Synchronized Groups page.
To delete users rather than disabling them, clear the box next to Disable users instead of deleting them.
To delete groups rather than moving them to a folder for future deletion, clear the box next to Defer deletion of groups instead of deleting.
To change the folder in which groups deferred for deletion are stored, click Browse and, in the Change Folder dialog box, select the folder and click OK.
By default, groups deferred for deletion are moved to a Groups to Delete folder in the same folder that stores the authentication source.
To edit an authentication source you must have at least Edit access to it.
On the Main Settings page, perform the following tasks as necessary:
Click the Synchronization page and perform the following tasks as necessary:
Under General Info, choose whether you want to use this authentication source to authenticate user credentials, import users and groups, or both:
To import users and groups and authenticate user credentials, choose Authentication and Synchronization. You must also specify what you want to synchronize (step 3).
To authenticate user credentials, but not import users and groups, choose Authentication Only.
To import users and groups, but use an authentication partner to authenticate user credentials, choose Synchronization with Authentication Partner. You must also specify the authentication partner (step 2), and what you want to synchronize (step 3).
If you chose Synchronization with Authentication Partner, in the Authentication Partners list, choose the authentication source you want to use for authentication (SSO or another authentication source).
Note:
If the authentication partner is unavailable, this authentication source will attempt to authenticate users.To use SSO as specified in the portal configuration file, choose SSO Authentication Source.
If you chose Authentication and Synchronization or Synchronization with Authentication Partner, specify what you want to synchronize.
Click the Fully Synchronized Groups page and perform the following tasks as necessary:
Click the Set Job page and perform the following task as necessary:
Click the Properties and Names page and perform the followings tasks as necessary:
Click the Security page and perform the following tasks as necessary:
Click the Migration History and Status page and perform the following tasks as necessary:
If this authentication source is set to synchronize users or groups, run the job associated with it.
Profile sources allow you to import user information (such as name, address, or phone number) that is already defined in your enterprise in existing user repositories, such as Active Directory or LDAP servers. The imported user information can be used to populate user profiles or can be passed to content crawlers, remote portlets, or federated searches as user information.
Note:
You must map the user information to portal properties on the User Information — Property Map (in the User Profile Manager) before you import the user information.
You must import users through an authentication source before you can import the associated user information.
You must run a job associated with the profile source to import the user information. You should continue to run the job periodically to keep the user information in the portal synchronized with the information in the source user repository.
A profile provider is a piece of software that tells the portal how to use the information in the external user repository. Oracle provides profile providers as part of the Oracle WebCenter Interaction Identity Services. The Oracle WebCenter Interaction Identity Service for LDAP is used to import user information from LDAP servers. The Oracle WebCenter Interaction Identity Service for Microsoft Active Directory is used to import user information from Active Directory servers. If your user information resides in a custom system, such as a custom database, you can import it by writing your own profile provider using the IDK.
Note:
Your portal administrator must install the profile provider before you can create the associated profile web service. For information on obtaining profile providers, refer to the Oracle Technology Network at http://www.oracle.com/technology/index.html. For information on installing profile providers, refer to the Installation Guide for Oracle WebCenter Interaction (available on the Oracle Technology Network at http://www.oracle.com/technology/documentation/bea.html) or the documentation that comes with your profile provider or contact your portal administrator.
To learn about developing your own profile provider, refer to the Oracle Fusion Middleware Web Service Developer's Guide for Oracle WebCenter Interaction, which is located on the Oracle Technology Network at http://www.oracle.com/technology/documentation/bea.html.
Profile web services enable you to specify general settings for your external user repository, leaving the more detailed settings (like domain specification) to be set in the associated remote profile sources. This allows you to create different profile sources to import information each domain without having to repeatedly specify all the settings.
User profiles provide information about users, such as address and position. You can view your information or information for other users.
Your portal administrator controls what information you see in a user profile, but the following categories of information are available by default:
General Information includes general contact information such as name, position, and phone number.
Folder Expertise lists the Knowledge Directory folders for which the user is a related expert. Your portal administrator might add a user to a folder as an expert, or, if you have the appropriate permissions, you can add yourself as expert when you are browsing folders in the Knowledge Directory. To open a listed Knowledge Directory folder, click the folder name.
Managed Communities lists the communities that the user has permission to manage. To view a listed community, click the community name.
Note:
The Folder Expertise and Managed Communities portlets do not display if your portal uses adaptive layouts.
If information contained in Folder Expertise or Managed Communities is incorrect, contact your portal administrator.
To view your user profile, in the portal banner, click My Account > View User Profile.
To view another user's profile, search for the user and click the user's name.
Note:
You can view only those properties to which you have access.You can add header and footer portlets to user profiles to control what users see at the top and bottom of the user profile pages.
To add headers and footers you must have the following rights and privileges:
Access Administration activity right
Access Utilities activity right
At least Select access to the header and footer portlets you want to add
Click Administration.
In the Select Utility list, select User Profile Manager.
Click the Header and Footer page.
Select the header and footer for the user profile pages.
To add or change the header, under Community Header, click Browse, then, in the Select a Header dialog box, select the header you want, and click OK.
To add or change the footer, under Community Footer, click Browse, then, in the Select a Footer dialog box, select the footer you want, and click OK.
To remove the header, under Community Header, click Remove.
To remove the footer, under Community Footer, click Remove.
You can update your user profile information, such as e-mail address or phone number.
User profile information can be viewed or searched by users or passed to certain portal objects for authentication or use as metadata.
In the portal banner, click My Account.
On the My Account page, click Edit User Profile.
Type the information you want to provide in the appropriate text boxes.
Note:
Your portal administrator may have populated some information automatically and may have set some information to read only.If there are multiple user profile pages listed on the left and you want to change information on another page, click the page name and change your information.
When you are done, click Finish to save your settings, or click Cancel to revert to your previous settings.
The User Information — Property Map enables you to map user information to user properties in the portal. The information in these user properties can then be displayed in the user's profile, or it can be sent to content crawlers, remote portlets, or federated searches so that users do not have to enter this information on a separate preference page.
To map user information to portal properties you must have the following rights and privileges:
Access Administration activity right
Access Utilities activity right
At least Select access to the properties you want to map
Note:
The Full Name attribute is automatically mapped to display name of the user unless you override it on this page.Click Administration.
In the Select Utility list, click User Profile Manager.
Under Edit Object Settings, click User Information - Property Map.
Add a property. Click Add; then, in the Choose Property dialog box, select the property you want to add and click OK.
Map attributes to the property:
Click the Edit icon next to the property name.
In the text box, type the attribute.
To map the property to multiple attributes, separate the attribute names with commas (,).
Repeat Steps 4 and 5 to map additional properties.
To remove properties, select the property you want to remove and click the Remove icon.
After mapping user information to portal properties, you need to import the user information through profile sources or have users manually enter the information by editing their user profiles.
Profile web services enable you to specify general settings for your external user repository, leaving the more detailed settings (like domain specification) to be set in the associated remote profile sources. This allows you to create different profile sources to import information each domain without having to repeatedly specify all the settings.
Before you create a profile web service, you must:
Install the profile provider on the computer that hosts the portal or on another computer
Create a remote server pointing to the computer that hosts the profile provider (optional, but recommended)
To create a profile web service you must have the following rights and privileges:
Access Administration activity right
Create Web Service Infrastructure activity right
At least Edit access to the parent folder (the folder that will store the profile web service)
At least Select access to the remote server that the profile web service will use
Click Administration.
Open the folder in which you want to store the profile web service.
In the Create Object list, click Web Service — Profile.
The Profile Web Service Editor opens.
On the Main Settings page, complete the following tasks:
Associate a remote server for the web service
Specify the path to the profile provider
Specify time-out settings for the web service
Enable the web service
Click the HTTP Configuration page and complete the following task:
Specify whether the content should be gatewayed
Click the Advanced Settings page and complete the following task:
Specify how information from this web service is encoded
Click the Authentication Settings page and complete the following task:
Specify what authentication information, if any, you want this web service to pass to its associated federated searches
Click the Debug Settings page and complete the following task:
Enable desired error tracing
Click the Properties and Names page and complete the following tasks:
Naming and Describing an Object
You can instead enter a name and description when you save this profile web service.
Localizing the Name and Description for an Object (optional)
Managing Object Properties (optional)
The default security for this profile web service is based on the security of the parent folder. You can change the security when you save this profile web service (on the Security tab page in the Save As dialog box), or by editing this profile web service (on the Security page of the Profile Web Service Editor).
Portal administrators with at least Select access to this profile web service can create profile sources based on the web service.
Profile sources allow you to import user information (such as name, address, or phone number) that is already defined in your enterprise in existing user repositories, such as Active Directory or LDAP servers. The imported user information can be used to populate user profiles or can be passed to content crawlers, remote portlets, or federated searches as user information.
Before you create a remote profile source, you must:
Import users with an authentication source.
If necessary, create portal properties for the attributes you want to import.
Associate the portal properties with the user object through the Global Object Property Map.
Map user attributes from the source user repository to portal properties with the User Information Property Map.
Install the profile provider on the computer that hosts the portal or on another computer.
Create a remote server that points to the computer that hosts the profile provider.
Create a profile web service on which to base the profile source.
To create a profile source you must have the following rights and privileges:
Access Administration activity right
Create Profile Sources activity right
At least Edit access to the parent folder (the folder that will store the authentication source)
At least Select access to the profile web service on which this profile source will be based
Click Administration.
Open the folder in which you want to store the profile source.
In the Create Object list, click Profile Source - Remote.
The Choose Web Service dialog box opens.
Select the web service that provides the basic settings for your profile source and click OK.
The Remote Portlet Editor opens, displaying the Main Settings page.
On the Main Settings page, complete the following tasks:
Click the Property Map page and complete the following task:
Click the Set Job page and complete the following task:
Click the Properties and Names page and complete the following tasks:
Naming and Describing an Object
You can instead enter a name and description when you save this profile source.
Localizing the Name and Description for an Object (optional)
Managing Object Properties (optional)
The default security for this profile source is based on the security of the parent folder. You can change the security when you save this profile source (on the Security tab page in the Save As dialog box), or by editing this profile source (on the Security page of the Profile Source Editor).
Run the job associated with this profile source.
Each profile source must include a unique key that is used to identify the user to the profile provider.
If the Profile Source Editor is not already open, open it now and display the Main Settings page.
Under Profile Unique Key, select the key that will be used to identify the user to the profile provider.
Remote Unique Name — This is the default. The user's imported unique name will be sent to the remote provider to identify the user. Common examples are the GUID or User Name.
Remote Authentication Name — The user's imported authentication name will be sent to the remote provider. In most cases, this is the same as the unique name.
User Property Value — The value of a property associated with each user will be sent to identify this user. Typically, this value is imported by another profile source.
If you select this option, you must also select which property to use: click Choose Property, in the Choose Property dialog box, select a property and click OK.
To change the selected property, click the property name.
You can select the users and groups for which user information should be imported.
If the Profile Source Editor is not already open, open it now and display the Main Settings page.
Under Profile Source Membership, select the users and groups for which user information should be imported.
To add users or groups, click Add Users/Groups; then, in the Profile Source Membership dialog box, select the users and groups you want to add and click OK.
To remove a user or group, select the user or group and click the Remove icon.
To select or clear all of the user and group boxes, select or clear the box to the left of Users/Groups.
To toggle the order in which the folders are sorted, click Users/Groups.
You can select the users and groups for which user information should be imported.
If the Profile Source Editor is not already open, open it now and display the Property Map page.
Specify how to map source user attributes to portal properties.
To add properties, click Add Property; then, in the Choose Property dialog box, select the properties you want to add and click OK.
To map a source user attribute to a portal property, click the Edit icon to the far right of the property, type the name of the attribute in the box, and click the Save icon to save the mapping.
To remove a mapping, select the mapping and click the Remove icon.
To select or clear all of the mapping boxes, select or clear the box to the left of Properties.
To toggle the order in which the properties are sorted, click Properties.
You can delete all user information previously imported by a profile source. This is useful when you add a new user property and want to look it up and update it for all users, or when you change a property from read-write to read-only and want to overwrite previous user modifications.
To delete user information imported by a profile source you must have the following rights and privileges:
Access Administration activity right
At least Edit access to the profile source
Click Administration.
Navigate to and open the profile source.
The Remote Portlet Editor opens, displaying the Main Settings page.
Click Clear History.
Run the job associated with the profile source to import the user information again.
Invitations allow you to direct potential users to your portal, making it easy for them to create their own user accounts and letting you customize their initial portal experiences with content that is of particular interest to them.
You should create a single invitation for all potential users who should be added to the same portal groups and should see the same communities, portlets, and My Pages when they first log in to your portal. After you create an invitation, you generate an invitation link to send to invitees. The invitation link expires after a specified number of users is created from the link or after the specified date. You can generate multiple invitation links for one invitation, each with different expiration settings.
To accept the invitation, the user clicks the link included in the e-mail and follows the directions to create a new user and log in to the portal. When the user logs in, the portlets, content, and communities specified in the invitation are displayed to the new user.
Users added by invitation are stored in the folder you specify in the invitation and are included in the WCI Authentication Source. They are automatically given security privileges based on the default profile you specify in the invitation. Based on this security, users can personalize their views of the portal with My Pages, portlets, and community memberships, and can view portal content.
Before you create an invitation, you must:
Create the default profile you want to apply to the users who accept the invitation.
Create the folder in which you want to store the users who accept the invitation.
To create an invitation you must have the following rights and privileges:
Access Administration activity right
Create Invitations activity right
At least Edit access to the parent folder (the folder that will store the invitation)
Click Administration.
Open the folder in which you want to store the invitation.
In the Create Object list, click Invitation.
The Invitation Editor opens, displaying the Main Settings page.
Select a folder in which to store the users who accept this invitation. Click Browse; then, in the Select a Folder dialog box, choose a folder and click OK.
If you want to display a particular experience definition interface to users when they log in, choose a folder to which the experience definition has been applied or apply the experience definition to the chosen folder before you send the invitation.
In the Default User Image list, select the default profile to apply to users who accept the invitation.
The default profile defines the user's initial view of the portal.
Select the groups to which you want to add users who accept the invitation.
To add invitees to a group, click Add Group; then, in the Select Groups dialog box, select the groups you want to add and click OK.
To remove a group from the list, select the group and click the Remove icon.
To select or clear all of the group check boxes, select or clear the box to the left of Group Name.
To toggle the order in which the groups are sorted, click Group Name.
After creating the invitation, you need to generate an invitation link and e-mail it to your invitees.
To send an invitation, you generate a link to e-mail to recipients. Recipients who follow this link are prompted to create a new account in your portal and can then begin customizing their views of your portal and exploring its contents.
Before you send an invitation, you must:
Create the invitation.
To send an invitation you must have the following rights and privileges:
Access Administration activity right
At least Edit access to the invitation
You can create
Click Administration.
Open the folder in which the invitation is stored.
Select the invitation and click Send Invitation.
The Send Invitation page opens.
If you have not already done so, create an invitation link. Click Create New Invitation Link.
If you have already created an invitation link with the expiration settings you want to use, skip to Step 6.
In the Create New Invitation Link dialog box, specify settings to prevent this link from being circulated and allowing unintended users access to secured content in your portal.
In the Name box, type a name for this link that makes clear to you and other portal administrators what this link is for.
In the Number of Invitations box, type the maximum number of users that can be created from this link.
In the Expiration Date box, type the date after which this link displays an error and will not allow users to create a portal account.
To choose the date from a calendar, click the Calendar icon.
To create the link, click Finish.
To display the invitation link, click the link name.
Copy and paste the invitation link into an e-mail, modify the message as desired, and send it to your invitees.
Note:
The only way to cancel an invitation is to delete the invitation, so be sure your invitation is correct before you e-mail it to anyone.The portal logs user activities, which allows you to query for actions taken by particular users, actions taken on a particular administrative object, or actions taken within a specified time period.
To configure user activity auditing and audit user activity you must have the following rights:
Access Administration activity right
Access Utilities activity right
Note:
You should configure activity logging to adequately meet the security auditing needs of your portal deployment and then implement procedures for periodically reviewing the audit records.You can specify what types of events should be logged.
To access the Audit Manager you must be a member of the Administrators Group.
Click Administration.
In the Select Utility list, click Audit Manager.
Under Message Types, specify what types of events should be logged:
| Message Type | Description |
|---|---|
| Item Change | Creates an entry every time an object is edited. |
| Item Deletion | Creates an entry every time an object is deleted. |
| Locked Account | Creates an entry every time a user account is locked after a number of failed login attempts. |
| Security Change | Creates an entry every time an object's security is edited. |
| User Login | Creates an entry every time a user successfully logs in to the portal. |
| Global System Change | Creates an entry every time an edit is made to the Global ACL Sync Map, the Global Property Map, the Global Content Type Map, the Global Object Property Map, or the User Information Property Map; every time job folders or Automation Services are registered; and every time global system settings are changed through the various portal utilities. |
You can query the user activity logs.
To access the Audit Manager you must be a member of the Administrators Group.
Click Administration.
In the Select Utility list, click Audit Manager.
Click the Create Audit Query page.
Under Search Criteria, limit the information returned by your query:
Note:
If you do not specify any information on this page, your query returns a description of every audit record that is stored in the database.To limit your query to a particular type of object, in the Item Type list, choose the object.
For example, you might want to see only audit messages referring to modifications of content crawlers.
To limit your query to objects of a particular name, in the Item Name box, type the text you want to search for and, in the list, choose whether you want your search for approximate or exact matches.
If you search for approximate matches, the portal returns items that include your text in any part of the name; if you search for exact matches, the portal returns only those items in which the item name equals the text you specify. For example, you could request only audit messages referring to actions on Sales content crawlers or Sales portlets by entering Sales in the text box and choosing Approximate.
To limit your query to actions performed by a particular user, in the Username box, type the text you want to search for and, in the list, choose whether you want to search for approximate or exact matches.
To limit your query to actions performed on a particular portal server, in the Server Name box, type the text you want to search for and, in the list, choose whether you want to search for approximate or exact matches.
For example, you could retrieve messages for all jobs run on the Automation Service named PortalJobs.
To limit your query to audit messages containing a particular word, in the Word in Message box, type the text you want to search for.
For example, to limit your query to all messages relating to a particular group, type the group name in this box.
To limit your query to particular types of messages, choose the types.
| Message Type | Description |
|---|---|
| Item Change | Entries corresponding to every time an object is edited. |
| Item Deletion | Entries corresponding to every time an object is deleted. |
| Locked Account | Entries corresponding to every time a user account is locked after a number of failed login attempts. |
| Security Change | Entries corresponding to every time an object's security is edited. |
| User Login | Entries corresponding to every time a user successfully logs in to the portal. |
| Global System Change | Entries corresponding to every time an edit is made to the Global ACL Sync Map, the Global Property Map, the Global Document Type Map, the Global Object Property Map, or the User Information Property Map; every time job folders or Automation Services are registered; and every time global system settings are changed through the various portal utilities. |
To limit your query to a particular period, in the Time Interval boxes, enter the starting and ending date and time you want to search.
Select the order in which you want to sort audit messages.
By default, the most recent audit messages are displayed first. To change the sort to display the oldest audit messages first, choose Oldest to newest.
In the Results per page box, type the maximum number of messages to display per page.
Click the Run Query page.
When you run an audit query, the results display on the Run Query page of the Audit Manager.
| Column | Description |
|---|---|
| Item Type | Displays the type of object that was modified: for example, Content Crawler, Portlet, or User. |
| Item Name | Displays the name of the object that was modified: for example, the Meeting Minutes Content Crawler. |
| User | Displays the name of the user who performed the action on the object. |
| Server | Displays the server from which the object was modified. |
| Message Type | Displays the type of action performed on the object: for example, User Login or Item Change. |
| Time | Displays the date and time the object was modified. |
| Message | Displays the text of the message. |
You can specify how and when to archive audit messages.
To access the Audit Manager you must be a member of the Administrators Group.
The Audit Log Management agent moves audit messages from the portal database into a collection of archive files and deletes old archive files based on the settings you configure in the Audit Manager. The Audit Log Management agent runs in the Audit Log Management Job, created upon installation and stored in the Intrinsic Operations folder. By default, this job runs daily. To change the frequency, edit the Audit Log Management Job.
Click Administration.
In the Select Utility list, click Audit Manager.
Under Archiving Agent, specify the settings for your auditing archive:
In the Network path of archive files box, type the path to the folder in which you want to store audit archive files.
In the Days to keep messages in database box, type the number corresponding to how many days worth of messages you want to store in the portal database.
Only messages in the portal database are available for audit query. After the specified amount of time, messages are moved from the database into the archive files.
In the Days to keep messages in files box, type the number corresponding to the number of days you want to store the message files.
After the specified period, messages are deleted from these files and no longer available.
When you configure user activity auditing, you can specify the frequency with which audit messages are deleted automatically.
To access the Audit Manager you must be a member of the Administrators Group.
Click Administration.
In the Select Utility list, click Audit Manager.
Under Delete Messages, specify which messages you want to delete from the portal database (they are not moved into the audit archive) and which archives you want to delete from your file system:
In the Delete Messages and Archives prior to box, type the date for which you want to delete messages and archives.
Any messages and archives with this date or an earlier date are deleted.
In the Message types to delete section, choose the types of messages that you want to delete from the database.
| Message Type | Description |
|---|---|
| Item Change | Entries corresponding to every time an object is edited. |
| Item Deletion | Entries corresponding to every time an object is deleted. |
| Locked Account | Entries corresponding to every time a user account is locked after a number of failed login attempts. |
| Security Change | Entries corresponding to every time an object's security is edited. |
| User Login | Entries corresponding to every time a user successfully logs in to the portal. |
| Global System Change | Entries corresponding to every time an edit is made to the Global ACL Sync Map, the Global Property Map, the Global Document Type Map, the Global Object Property Map, or the User Information Property Map; every time job folders or Automation Services are registered; and every time global system settings are changed through the various portal utilities. |
If you want to delete these messages and archives when you click Finish, select Yes next to Delete Messages and Archives when 'Finish' is clicked.
|
 Copyright © 2009, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
