| Oracle® Fusion Middleware Administrator's Guide for Oracle WebCenter Interaction 10g Release 4 (10.3.3.0.0) Part Number E14107-05 |
|
|
View PDF |
| Oracle® Fusion Middleware Administrator's Guide for Oracle WebCenter Interaction 10g Release 4 (10.3.3.0.0) Part Number E14107-05 |
|
|
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.
It includes the following sections:
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 Oracle Fusion Middleware 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).
This section describes the types of users you might have in your deployment:
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. For more information on authentication sources, see About Importing and Authenticating Users and Groups.
You can also use profile sources to 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. For more information on profile sources, see About Importing User Profile 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. For more information on invitations, see About Invitations.
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 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.
This section describes the following main tasks:
It also covers the following low-level tasks:
To create a user you must have the following rights and privileges:
Access Administration activity right
Create Users activity right
At least Edit access to the parent folder (the folder that will store the user)
At least Select access to any groups to which you want to add this user
To edit a user you must have the following rights and privileges:
Access Administration activity right
At least Edit access to the user
At least Select access to any groups to which you want to add this user
To create or edit a user:
Click Administration.
Open the User Editor.
To create a user, open the folder in which you want to store the user. In the Create Object list, click User.
To edit a user, open the folder in which the user is stored and click the user name.
On the Main Settings page, perform tasks as necessary:
On the Mobile Device Authentication page, perform tasks as necessary:
On the Properties and Names page, perform tasks as necessary:
If you are editing a user, on the Migration History and Status page, perform tasks as necessary:
Note:
The Migration History and Status page is not available when creating an object.
Note:
User security is inherited from the folder in which the user is stored. If you do not want a user to be returned in some users' searches, ensure that those users are not allowed access to the folder in which the user is stored.
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 (whose account is not locked):
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.
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.
This section describes the following tasks:
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, select 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, 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
To manually lock a user account:
Click Administration.
Navigate to the user whose account you want to lock and click the user name.
Select Disable Login.
The lock on user 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: An administrative user with Admin access to the user 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.
To specify the authentication settings for a user:
If the User Editor is not already open, open it now. The User Editor displays the Main Settings page.
In the Login Name box, type the name this user must enter to log in to the portal.
In the Password box, type the password this user must enter to log in to the portal.
In the Confirm Password box, type the same password as in step 3.
If you do not want this user to be allowed to log in, select Disable Login.
To make this a guest user, select This is a guest account. Once you save this user, this check box is unavailable (grayed out). You can create multiple guest users and associate them to different experience definitions. Click here for an example.
To add a user to groups:
If the User Editor is not already open, open it now. The User Editor displays to the Main Settings page.
Under Group Memberships, specify the groups of which this user should be a member. This user will have access to all the content and portal activities to which these groups have access. All users are part of the Everyone group:
To add this user to a group, click Add Group, in the Select Groups dialog box, select the groups you want to add, and click OK.
To remove this user from a group, select the group and click the Remove icon.
To select or clear all of the group boxes, select or clear the box to the left of Groups.
To toggle the order in which the groups are sorted (ascending/descending), click Groups.
Dynamic group membership is based on dynamic membership rules, specific values in the user's profile, or membership in other groups. You can view the dynamic group memberships for a user on the Main Settings page of the User Editor, under Dynamic Group Memberships.
Each user is assigned a default profile at creation, based on settings in the authentication source or the invitation (manually created users and self-registered users are automatically assigned the “Default Profile” created at installation. 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.
This section describes the following tasks:
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 or edit a default profile you need the following rights:
Access Administration activity right
Access Utilities activity right
To create or edit a default profile:
Click Administration.
In the Select Utility list, click Default Profiles.
The Default Profiles folder opens.
Open the Default Profile Editor.
To create a default profile, in the Create Object list, click User.
To edit a default profile, click the default profile name.
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 or edited 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
To customize a default profile:
If you are not already in the Default Profiles folder, click Administration, and, in the Select Utility list, click Default Profiles.
Select the profile 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.
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.
This section describes the types of groups you might have in your deployment:
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 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 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: |
All activity rights; add the user to the Administrators group, which has all activity rights |
|
Content Administrator: |
|
|
Community Creator |
|
|
Portlet Creator |
|
|
Group/User Creator |
|
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.
When creating a group hierarchy, begin with the users with the least rights and work towards the most powerful users. A group inherits the rights of its parent group, so the broadest groups with the least rights should be parent to more specific groups with greater rights.
For example, the engineering department creates an Engineer group (for all members of the department). The QA subset of the engineering department requires special access to certain bug tracking software, so a QA group should be created with the Engineer group as a parent. Administrative tasks on the bug tracking software is restricted to QA managers, so a group inheriting from the QA group is created for QA managers.
This section describes the following main tasks:
It also covers the following low-level tasks:
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
To edit a group you must have the following rights and privileges:
Access Administration activity right
At least Edit access to 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
To create or edit a a group:
Click Administration.
Open the Group Editor.
To create a group, open the folder in which you want to store the group. In the Create Object list, click Group.
To edit a group, open the folder in which the group is stored and click the group name.
On the Group Memberships page, perform tasks as necessary:
On the Dynamic Membership Rules page, perform tasks as necessary:
On the Activity Rights page, perform tasks as necessary:
On the Properties and Names page, perform tasks as necessary:
On the Security page, perform tasks as necessary:
If you are editing a user, on the Migration History and Status page, perform tasks as necessary:
Note:
The Migration History and Status page is not available when creating an object.
To delete a group you must have the following rights and privileges:
Access Administration activity right
Admin access to the group
To delete a group:
Click Administration.
Navigate to the group.
Select the group you want to delete and click the delete icon.
Caution:
If users were previously granted rights and privileges based on being a member of this group, they will no longer have those rights and privileges.
To specify the groups to which this group should be a member:
If the Group Editor is not already open, open it now. The Group Editor displays the Group Memberships page.
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.
To specify the members of this group:
If the Group Editor is not already open, open it now. The Group Editor displays the Group Memberships page.
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.
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.
If the Group Editor is not already open, open it now.
On the left, under Edit Object Settings, click Dynamic Membership Rules.
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.
On the left, under Edit Object Settings, click Activity Rights.
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 to remove and click the Remove icon.
Under Inherited Activity Rights you see any activity rights granted to the parent groups of this group.
Rather than recreating users, groups, and group memberships to use in your portal, you can leverage the structure and security you already have defined in your existing user repositories, such as Active Directory or LDAP servers.
This section describes the components involved in importing and authenticating users and how the process works:
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, meaning 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.
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 for the following types of user repositories as part of Oracle WebCenter Interaction:
LDAP
Microsoft Active Directory
Note:
You must install the authentication provider before you can create the associated authentication Web service. For information on installing authentication providers, refer to the Oracle Fusion Middleware Installation Guide for Oracle WebCenter Interaction for Windows or the Oracle Fusion Middleware Installation Guide for Oracle WebCenter Interaction for Unix and Linux).
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. For details, see the Oracle Fusion Middleware Web Service Developer's Guide for Oracle WebCenter Interaction.
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, enabling 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).
Creating separate synchronization-only authentication sources for each domain 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.
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.
This section describes the following main tasks:
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
To edit an authentication Web service you must have the following rights and privileges:
Access Administration activity right
At least Edit access to the authentication Web service
If you must change the remote server association, at least Select access to the remote server that the authentication Web service will use
To create or edit an authentication Web service:
Click Administration.
Open the Authentication Web Service Editor.
To create an authentication Web service, open the folder in which you want to store the authentication Web service. In the Create Object list, click Web Service — Authentication.
To edit an authentication Web service, open the folder in which the authentication Web service is stored and click the authentication Web service name.
On the Main Settings page, perform tasks as necessary:
On the HTTP Configuration page, perform tasks as necessary:
On the Advanced Settings page, perform tasks as necessary:
On the Authentication Settings page, perform tasks as necessary:
On the Debug Settings page, perform tasks as necessary:
On the Associated Objects page, perform tasks as necessary:
On the Properties and Names page, perform tasks as necessary:
Naming and Describing an Object
You can instead enter a name and description when you save this authentication Web service.
On the Security page, perform tasks as necessary:
The default security for this authentication Web service is based on the security of the parent folder. Administrative users with at least Select access to this authentication Web service and the Create Authentication Source activity right can create authentication sources based on the Web service.
If you are editing an authentication Web service, on the Migration History and Status page, perform tasks as necessary:
Note:
The Migration History and Status page is not available when creating an object.
To delete an authentication Web service you must have the following rights and privileges:
Access Administration activity right
Admin access to the authentication Web service
To delete an authentication Web service:
Click Administration.
Navigate to the authentication Web service.
Select the authentication Web service you want to delete and click the delete icon.
Note:
Deleting an authentication Web service will break any associated authentication sources.
This section describes the following main tasks:
It also covers the following subtasks:
Setting Default Profiles and Target Folders for Imported Users
Specifying What to Do with Users and Groups Deleted from the Source User Repository
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
To create an authentication source to import and authenticate users:
Open the folder in which you want to store the authentication source.
In the Create Object list, click Authentication Source - Remote.
Select the Web service that provides the basic settings for your authentication source and click OK.
The Remote Authentication Source Editor opens.
On the Synchronization page, perform the following tasks:
Under General Info, select Authentication and Synchronization.
Specify what to synchronize. For details, see Specifying Which Users and Groups to Synchronize.
On the Fully Synchronized Groups page, perform the following task:
On the Properties and Names page, perform 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.
Managing Object Properties (optional)
On the Security page, perform the following task:
Setting Security on an Object (optional)
The default security for this authentication source is based on the security of the parent folder.
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.
To create a synchronization-only 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 Fully Synchronized Groups page, perform the following task:
On the Set Job page, perform the following task:
On the Properties and Names page, perform 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.
Managing Object Properties (optional)
On the Security page, perform the following task:
Setting Security on an Object (optional)
The default security for this authentication source is based on the security of the parent folder.
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
To create an authentication-only 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 Synchronization page, under General Info, select Authentication Only.
On the Properties and Names page, perform 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.
Managing Object Properties (optional)
On the Security page, perform the following task:
Setting Security on an Object (optional)
The default security for this authentication source is based on the security of the parent folder.
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
To create an SSO 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, perform the following tasks:
Make a note of this string, Unless this string matches the PrefixHeading of the authentication provider, you must configure for the DefaultAuthSourcePrefix setting in the portalconfig.xml file, as described in Configuring the Portal for SSO.
Setting Default Profiles and Target Folders for Imported Users
On the Synchronization page, perform the following tasks:
Under General Info, select Synchronization with Authentication Partner.
In the Authentication Partners list, select SSO Authentication Source.
On the Fully Synchronized Groups page, perform the following task:
On the Set Job page, perform the following task:
On the Properties and Names page, perform 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.
Managing Object Properties (optional)
On the Security page, perform the following task:
Setting Security on an Object (optional)
The default security for this authentication source is based on the security of the parent folder.
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, modify the portal configuration to enable SSO. For details, see Appendix E, "Deploying Single Sign-On."
To edit an authentication source you must have the following rights and privileges:
Access Administration activity right
At least Edit access to the authentication source
To edit an authentication source:
Click Administration.
Open the folder in which the authentication source is stored and click the authentication source name.
On the Main Settings page, perform tasks as necessary:
On the Synchronization page, perform 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.
If you have users and groups distributed among different authentication sources, you can allow groups in this authentication source to include users from another authentication source. To do this, select Import user and group memberships from other authentication sources.
In the Import batches of text 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.
On the Fully Synchronized Groups page, perform tasks as necessary:
On the Set Job page, perform tasks as necessary:
On the Properties and Names page, perform tasks as necessary:
On the Security page, perform tasks as necessary:
On the Migration History and Status page, perform tasks as necessary:
If this authentication source is set to synchronize users or groups, run the job associated with it.
To delete an authentication source you must have the following rights and privileges:
Access Administration activity right
Admin access to the authentication source
To delete an authentication source:
Click Administration.
Navigate to the authentication source.
Select the authentication source you want to delete and click the delete icon.
Note:
Deleting an authentication source that authenticates users will mean that the users will not be able to log in to the portal.
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.
This prefix is used in conjunction with the Global ACL Sync Map to map security from source content repositories to the security in the portal. For details on the Global ACL Sync Map, see Mapping External Document Security to Imported Portal Users with the Global ACL Sync Map.
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 plan 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 must 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 must 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.
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.
Users imported through an authentication source can automatically be granted access to the content imported by some remote content crawlers through mappings in the Global ACL Sync Map.
The Global ACL Sync Map is used by content crawlers bringing security settings, in the form of Access Control Lists (ACLs), into your portal along with documents. The Global ACL Sync Map shows content crawlers how the users and groups found on source document ACLs correspond with portal users and groups. Using this information, a content crawler can set portal security on imported content. For an example-based explanation of this process, see Example of Importing Content Security.
Every authentication source has a prefix. This prefix is used to distinguish the users and groups imported through the authentication source. If you plan to import security information with imported content, you might must map your authentication source prefixes to the source domains or map portal groups to external groups through the Global ACL Sync Map.
Note:
If your authentication source prefix matches the domain name, the mapping occurs automatically and you do not must add the mapping to this page.
To access the Global ACL Sync Map you must be a member of the Administrators group.
To open the Global ACL Sync Map:
Click Administration.
From the Select Utility menu, choose Global ACL Sync Map.
On the Prefix: Domain Map page map authentication source prefixes to source domains:
To add a prefix to the map, click Add Mapping; then, in the Select Authentication Sources dialog box, select the authentication sources you want to map and click OK.
Note:
If more than one authentication source uses the same prefix, you only must map one of the authentication sources.
To edit the prefix in this mapping (this will not affect the prefix in the authentication source), in the Authentication Source Prefix column, click the edit icon. In the text box that displays, edit the name, then click the arrow icon to save your change.
To specify which domains map to a selected prefix, in the Domain Name column, click the edit icon and, in the text box that displays, type the domains you want to map, separated by commas (,). Click the arrow 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 check boxes, select or clear the box to the left of Authentication Source Prefix.
To toggle the order in which the mappings are sorted (ascending/descending), click Authentication Source Prefix or click the icon to the right of that.
User profiles provide information about users, such as address, position, or whatever other information you want. User profiles can be accessed from several different contexts, but are always available to end users as a series of portlets accessible through the My Account menu, with the View User Profile option.
There are several features associated with controlling and populating user profiles:
You can change the portlets displayed on the user profile pages through the User Profile Manager (see Editing a Profile Page).
Some user profile portlets are installed with the portal software and automatically added to the user profile pages:
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.
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.
You can also create new portlets to suit your needs. For more information on portlets, see Chapter 8, "Extending Portal Services with Portlets."
You can change the properties displayed in the user profile portlets through the administrative preferences page of the user profile portlet (accessible through the Main Settings page of the Portlet Editor). For information on these administrative preferences, see Configuring a User Profile Portlet.
The values for properties in the user profile are either manually entered by the user on the Edit User Profile page or automatically populated by a profile source.
Note:
The Folder Expertise portlet displays the list of folders for which the user is an expert. You can add users to a folder as an expert through the Related Resources page of the Folder Editor, or, if users have the Self-Selected Experts activity right, they can add themselves as experts when they are browsing folders in the Directory. The Managed Communities portlet displays the list of communities managed by the user. This portlet is automatically populated with all the communities to which the user has Edit or Admin access.
You can limit the information displayed in user profiles by restricting access to the user profile portlets and the properties displayed in those portlets. For example, you might want to display employee contact information both to customers and employees but want to restrict reporting hierarchy information to display only to employees. You could create two separate user profile portlets—one for your customers (containing the contact information properties) and another one for your employees (containing the contact information and reporting hierarchy properties). However, you could instead just create one user profile portlet, containing the contact information and reporting hierarchy properties, but limit the security on the reporting hierarchy properties to allow only employees Select access. Users that have Select access to a property can view the value of that property for other users. Users who have Read access to a property can view only their own values; when they view the profile of another user, that property is hidden.
The user profile is really just a special community, accessed through the User Profile Manager. By default, the user profile consists of a single page populated with three user profile portlets—General Information, Folder Expertise, and Managed Communities. As with any community, you can add additional portlets and pages and can change the community template used for the user profile to enhance the user experience.
This section describes the following main tasks:
It also covers the following low-level tasks:
Adding or Editing the Header and Footer on User Profile Pages
Associating User Information with Properties Using the User Information — Property Map
To access the User Profile Manager you must have the following rights and privileges:
Access Administration activity right
Access Utilities activity right
To manage the user profile:
Click Administration.
In the Select Utility list, select User Profile Manager.
On the Profile Pages page, perform tasks as necessary:
On the Header and Footer page, perform tasks as necessary:
On the This Community's Portlets page, perform tasks as necessary:
On the User Information - Property Map page, perform tasks as necessary:
On the Properties and Names page, perform tasks as necessary:
On the Security page, perform tasks as necessary:
On the Migration History and Status page, perform tasks as necessary:
User profile portlets are made up of:
Properties: Profile information—such as name, author, and title—are stored with users as properties. These properties, like those associated with any other type of object—such as content crawlers and documents—can be searched (if they are set as searchable in the Property Editor).
Just as with other objects, a property of a user has the same value regardless of where it is displayed. For example, if you want to display your users' home phone numbers in a Home Information Profile portlet and their work phone numbers in a Work Information Profile portlet, you must create separate "Work Phone" and "Home Phone" properties and display them in the respective portlets. If you only have a single "Phone" property, then the value of the Phone property would be the same in both profile portlets.
Categories: Categories are organized groups of properties. Categories let you organize the display order of properties and provide context for what type of information is being displayed.
You can change the categories and properties displayed in the user profile portlets through the administrative preferences page of the user profile portlet.
To configure a user profile portlet:
Click Administration.
Navigate to the user profile portlet you want to edit and click its name.
Add or edit properties and categories as necessary:
To add a new category, click New Category. In the New Category dialog box, type a name and description, then click Finish.
To add a new property to a category, under the category, click Add Property. In the Add Properties dialog box, select the properties you want to add, and click OK.
To change a category name or description, click Rename Categories. In the Rename Categories dialog box, click the category you want to rename. In the Names and Descriptions dialog box, type a name and a description, and click Finish. When you are done renaming all the categories, click Close.
To arrange the order of properties and categories (for categories, click Manage Categories first):
To move the selection to the top of the list, click the move to top icon.
To move the selection up, click the move up icon.
To move the selection down, click the move down icon.
To move the selection to the bottom of the list, click the move to bottom icon.
To remove a property or a category (for categories, click Manage Categories first), select the properties or categories you want to delete and click the remove icon.
To localize a category name and description:
Click Rename Categories.
In the Rename Categories dialog box, select the category you want to localize. The Names and Descriptions dialog box appears.
If you did not set a mandatory object language in the portal configuration file, in the Primary Language list, select the language for the name and description you entered.
If you did set a mandatory object language in the portal configuration file, you see the mandatory language instead of a list. You cannot change this setting. The name and description you entered must be in the mandatory language.
If a localized name and description is not available in a user's selected language, the user will see the name and description in the specified primary language.
Select Supports Localized Names.
The Localized Names and Descriptions section appears.
Add localized names and descriptions as necessary. Click New Localized Name. This displays the Name and Description dialog box. In the Name box, type the localized name for this category. In the Language drop-down list, choose the language for which you are adding a name and description. In the Description box, type the localized description for this category. When you are done, click Finish.
The community template determines a set of required pages and—if configured—enforces a header and a footer.
Caution:
When changing the community template, note the following:
Any pages from the old community template that are not part of the new community template will be removed.
If you have set special headers and footers for the profile pages, switching to a community template that enforces a header or footer will remove your header or footer.
To change the community template:
If the User Profile Manager is not already open, open it now.
In the Community Template section, click Change Community Template. This displays the Community Templates dialog box.
Select a template and click OK.
If you do not want the profile pages to inherit future changes to the template, clear the box next to Inherit the Template.
If you select to inherit changes, any change applied to the community template affects the profile pages. For example, if a page is removed from the community template, the page will be removed from the profiles as well. Additionally, if you inherit changes, you cannot delete pages associated with the template, but you can add new pages and change the order of the pages.
Click OK.
The order in which pages are displayed in the Profile Pages list is the order in which the page links will display to users.
If the User Profile Manager is not already open, open it now.
In the Profile Pages section, change the order of the pages:
To move a page to the top of this list, click the move to top icon.
To move a page up one space in this list, click the move up icon.
To move a page down one space in this list, click the move down icon.
To move a page to the bottom of this list, click the move to bottom icon.
When you create a new page, you must choose a page template. This page template determines the default page name, a set of required portlets, and the page layout.
To add a profile page:
If the User Profile Manager is not already open, open it now.
In the Profile Pages section, click New Page.
Select a page template and click OK.
If you do not want the profile pages to inherit future changes to the template, clear the box next to Inherit the Template.
If you select to inherit changes, any change applied to the community template affects the profile pages. For example, if a page is removed from the community template, the page will be removed from the profiles as well. Additionally, if you inherit changes, you cannot delete pages associated with the template, but you can add new pages and change the order of the pages.
Click OK.
You can delete any page that says No in the From Community Template column. If you chose to inherit changes from the community template, pages that are part of that template say Yes in the From Community Template column and cannot be deleted.
To delete a profile page:
If the User Profile Manager is not already open, open it now.
In the Profile Pages section, select the page and click the delete icon.
Depending on whether you are inheriting changes, you can change the page name, add portlets, delete portlets, rearrange portlets, change the page layout, and set page security.
To edit a profile page:
If the User Profile Manager is not already open, open it now.
In the Profile Pages section, click the name of the page.
Edit the page as necessary.
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 or edit the 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
To add or edit the headers and footers on user profile pages:
If the User Profile Manager is not already open, open it now.
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.
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.
If the User Profile Manager is not already open, open it now.
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 3 and 4 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 must import the user information through profile sources or have users manually enter the information by editing their user profiles.
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.
This section describes the pieces that work together to make importing user information work. It covers the following topics:
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 Identity Service for LDAP is used to import user information from LDAP servers. The Oracle WebCenter 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:
You must install the profile provider before you can create the associated profile Web service. For information on installing profile providers, refer to the Oracle Fusion Middleware Installation Guide for Oracle WebCenter Interaction for Windows or the Oracle Fusion Middleware Installation Guide for Oracle WebCenter Interaction for Unix and Linux).
To learn about developing your own profile provider, refer to the Oracle Fusion Middleware Web Service Developer's Guide for Oracle WebCenter Interaction.
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, enabling you to create different profile sources to import information each domain without having to repeatedly specify all the settings.
Profile sources allow you to import user information (such as name, address, or phone number) from external user repositories. User information can exist anywhere in your enterprise:
If the information resides on an Active Directory server, you can create an Active Directory remote profile source to extract it.
If the information resides on an LDAP server, you can create an LDAP remote profile source to extract it.
If the information resides in a custom system, such as a custom database, you can easily extract the information by writing your own remote profile provider, using IDK and then create a remote profile source to extract the 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.
This section describes the following main tasks:
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, enabling 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
To edit a profile Web service you must have the following rights and privileges:
Access Administration activity right
At least Edit access to the profile Web service
If you plan to change the remote server association, at least Select access to the remote server that the profile Web service will use
To create or edit a profile Web service:
Click Administration.
Open the Profile Web Service Editor.
To create a profile Web service, open the folder in which you want to store the profile Web service. In the Create Object list, click Web Service — Profile.
To edit a profile Web service, open the folder in which the profile Web service is stored and click the profile Web service name.
On the Main Settings page, perform tasks as necessary:
On the HTTP Configuration page, perform tasks as necessary:
On the Advanced Settings page, perform tasks as necessary:
On the Authentication Settings page, perform tasks as necessary:
On the Debug Settings page, perform tasks as necessary:
On the Associated Objects page, perform tasks as necessary:
On the Properties and Names page, perform tasks as necessary:
Naming and Describing an Object
You can instead enter a name and description when you save this authentication Web service.
On the Security page, perform tasks as necessary:
The default security for this profile Web service is based on the security of the parent folder. Administrative users with at least Select access to this profile Web service can create profiles sources based on the Web service.
If you are editing a profile Web service, on the Migration History and Status page, perform tasks as necessary:
Note:
The Migration History and Status page is not available when creating an object.
To delete a profile Web service you must have the following rights and privileges:
Access Administration activity right
Admin access to the profile Web service
To delete a profile Web service:
Click Administration.
Navigate to the profile Web service.
Select the profile Web service you want to delete and click the delete icon.
Note:
Deleting a profile Web service will break any associated profile sources.
This section describes the following main tasks:
It also covers the following low-level tasks:
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 profile source)
At least Select access to the profile Web service on which this profile source will be based
To create a profile source you must have the following rights and privileges:
Access Administration activity right
At least Edit access to the profile source
To create or edit a profile source:
Click Administration.
Open the Profile Source Editor.
To create a profile source, open the folder in which you want to store the profile source. In the Create Object list, click Profile Source - Remote. In the Choose Web Service dialog box, select the Web service that provides the basic settings for your profile source and click OK.
To edit a profile source, open the folder in which the profile source is stored and click the profile source name.
On the Main Settings page, perform tasks as necessary:
On the Property Map page, perform tasks as necessary:
On the Set Job page, perform tasks as necessary:
On the Properties and Names page, perform tasks as necessary:
Naming and Describing an Object
You can instead enter a name and description when you save this profile source.
On the Security page, perform tasks as necessary:
The default security for this profile source is based on the security of the parent folder.
If you are editing a profile Web service, on the Migration History and Status page, perform tasks as necessary:
Note:
The Migration History and Status page is not available when creating an object.
Run the job associated with this profile source.
To delete a profile source you must have the following rights and privileges:
Access Administration activity right
Admin access to the profile source
To delete a profile source:
Click Administration.
Navigate to the profile source.
Select the profile source you want to delete and click the delete icon.
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.
This section describes the following tasks:
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)
To edit an invitation you must have the following rights and privileges:
Access Administration activity right
At least Edit access to the invitation
To create or edit an invitation:
Click Administration.
Open the Invitation Editor.
To create an invitation, open the folder in which you want to store the invitation. In the Create Object list, click Invitation.
To edit an invitation, open the folder in which the invitation is stored and click the invitation name.
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 must 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 administrative users 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.
To delete an invitation you must have the following rights and privileges:
Access Administration activity right
Admin access to the invitation
To delete an invitation:
Click Administration.
Navigate to the invitation.
Select the invitation you want to delete and click the delete icon.
The portal logs user activities, which enables 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.
To configure user activity auditing and audit user activity:
Click Administration.
In the Select Utility list, click Audit Manager.
On the Main Settings page, perform tasks as necessary:
On the Create Audit Query page, perform tasks as necessary:
On the Run Query page, you see the results of your query. For details, see User Activity Audit Query Results.
You can specify what types of events should be logged.
To access the Audit Manager you must be a member of the Administrators Group.
If the Audit Manager is not already open, open it now.
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.
If the Audit Manager is not already open, open it now.
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. For details on the results, see User Activity Audit Query Results.
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.
If the Audit Manager is not already open, open it now.
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.
If the Audit Manager is not already open, open it now.
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 before 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 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 © 2011, 2013, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
