8 OPSS Authorization and the Policy Store

8.2.1.1 Setting Up a One- Way SSL Connection

This section describes how to set up a one-way SSL channel between the Oracle WebLogic server and a target LDAP Oracle Internet Directory store to reassociate domain stores. This setup should be in place before using Fusion Middleware Control or the WLST command reassociateSecurityStore.

Prerequisite: Configuring the Oracle Internet Directory Server

To configure the Oracle Internet Directory server to listen in one-way SSL mode, see section Enabling SSL on Oracle Internet Directory Listeners in Oracle Fusion Middleware Administrator's Guide.

Exporting Oracle Internet Directory's Certificate Authority (CA)

The use of orapki to create a certificate is needed only if the CA is unknown to the Oracle WebLogic server.

The following sample illustrates the use of this command to create the certificate serverTrust.cert:

>orapki wallet export -wallet CA -dn "CN=myCA" -cert serverTrust.cert

The above invocation prompts the user to enter the keystore password.

Setting Up the WebLogic Server

To set up the server whose domain includes the stores to be reassociated, proceed as follows:

1. If the CA is known to the Oracle WebLogic server, skip this step; otherwise, use the utility keytool to import the Oracle Internet Directory's CA into the WebLogic truststore.

   The following invocation, which outputs the file myKeys.jks, illustrates the use of this command to import the file serverTrust.cert:

   >keytool -import -v -trustcacerts -alias trust -file serverTrust.cert -keystore myKeys.jks -storepass keyStorePassword
   

2. Use the WebLogic Administration Console to set, in the appropriate domain, a truststore that points to the file myKeys.jks, as follows:

   1. Navigate to Environment > Servers.

   2. Select the name of the administration server in your domain.

   3. Select the tab Keystore.

   4. Change the keystore mode from Demo Identity and Demo Trust to Custom Identity and Custom Trust.

   5. In the Trust section enter data as follows: in the field Custom Trust Keystore, enter the absolute path name of the keystore file myKeys.jks; in the field Keystore Type, enter JKS; in the fields Custom Trust Keystore Passphrase and Confirm Custom Trust Keystore Passphrase, enter the keystore password.

3. Modify the script (typically startWebLogic.sh) that starts your server to include a line like the following, and then restart the server:

   -Djavax.net.ssl.trustStore=<absolute path name to file myKeys.jks>
   

8.2.1.2 Securing Access to Oracle Internet Directory Nodes

The procedure explained in this section is optional and performed only to enhance the security to access an Oracle Internet Directory.

An access control list (ACL) is a list that specifies who can access information and what operations are allowed on the Oracle Internet Directory directory objects. The control list is specified at a node, and its restrictions apply to all entries in the subtree under that node.

ACL can be used to control the access to policy and credential data stored in an LDAP Oracle Internet Directory repository, and it is, typically, specified at the top, root node of the store.

To specify an ACL at a node in an Oracle Internet Directory repository, proceed as follows:

1. Create an LDIF file with a content that specifies the ACL:

   dn: <storeRootDN>
   changetype: modify
   add: orclACI
   access to entry by dn="<userDN>" (browse,add,delete) by * (none)
   access to attr=(*) by dn="<userDN>" (search,read,write,compare) by * (none)
   

   where storeRootDN stands for a node (typically the root node of the store), and userDN stands for the DN of the administrator data (the same userDN that was entered to perform reassociation).

2. Use the Oracle Internet Directory utility ldapmodify to apply these specifications to the Oracle Internet Directory.

Here is an example of an LDIF file specifying an ACL:

dn: cn=jpsRootNode
changetype: modify
add: orclACI
access to entry by dn="cn=myAdmin,cn=users,dc=us,dc=oracle,dc=com" (browse,add,delete) by * ( none )
access to attr=(*) by dn="cn=myAdmin,cn=users,dc=us,dc=oracle,dc=com" (search,read,write,compare) by * (none)

For more information about access control lists and the command ldapmodify, see chapter 18 in Oracle Fusion Middleware Administrator's Guide for Oracle Internet Directory.

8.3.2.1 Examples of Use

For complete examples illustrating the use of this command, see Section 7.5.2.1, "Migrating Policies Manually."

8.4.1.1 Managing Application Policies

This section explains the steps you follow to manage the policies of a deployed application with Fusion Middleware Control, such as, for example, to change the permission grants of an existing application role. To manage system policies, see Managing System Policies.

1. Log in to Fusion Middleware Control and navigate to Application > Security > Application Policies, to display the Application Policies page for the selected Application. This page is partially shown in the following graphic:

   
   

   The area Policy Store Provider is read-only and, when expanded, displays the policy store provider currently in use in the domain where the application is deployed.

   Note:

   If the page does not initially display policies and roles, click the blue button to display all items.

2. To display existing application policies matching a given principal or permission, expand the Search area, as necessary, enter the data to match (a principal or a permission or both), and click the blue button. The results of the search are displayed in the table at the bottom of the page.

3. To create an application policy, click Create to display the Create Application Grant page. The top area Grant Details displays read-only information about the application.

   1. To add permissions to the policy being created, click Add in the Permissions area to display the Add Permission dialog.

      Using the Search to identify permissions matching a class or resource name, determine the Permission Class and Resource Name of the permission. Optionally, use the Customize area to further qualify the permission.

      When finished, click OK to return to the Create Application Grant page. The permission you created is displayed in the table in the Permissions area.

   2. To add a user to the policy being created, click the button Add User in the Grantee area to display the dialog Add User.

      Using the Search, identify users names matching a string; the result of the query is displayed in the Available Users box.

      Using the various buttons, move the users you want to grant permissions from the Available Users box to the Selected Users box.

      When finished, click OK to return to the Create Application Grant page. The users you selected are displayed in the table in the Grantee area.

   3. To add a role to policy being created, click the button Add Role in the Grantee area to display the dialog Add Role.

      Using the Search, identify role names matching a type or name; the result of the query is displayed in the Available Roles box.

      Using the various buttons, move the roles you want to grant permissions from the Available Roles box to the Selected Roles box.

      When finished, click OK to return to the Create Application Grant page. The roles you selected are displayed in the table in the Grantee area.

   4. At any point you can remove a selected item using the Delete button.

   5. When finished, click OK to return to the Application Policies page. The principal and permissions of the policy created are displayed in the table at the bottom of the page.

4. To create an application policy based on an existing one:

   1. Select an existing policy from the table.

   2. Click Create Like, to display the Create Application Grant page. Notice that in this page all the permissions are automatically filled in with the data extracted from the policy you selected.

   3. Modify those values and enter users and roles, as appropriate, as explained in the substeps of step 3 above.

8.4.1.2 Managing Application Roles

This section explains the steps you follow to manage the roles of a deployed application with Fusion Middleware Control. Management operations that control the access a user or group has to resources, include creating application roles, mapping an application role to users, groups, or other application roles, and managing the members in application roles.

1. Log in to Fusion Middleware Control and navigate to Application > Security > Application Roles, to display the Application Roles page. This page is partially shown in the following graphic:

   
   

   The area Policy Store Provider is read-only and, when expanded, displays the policy store provider currently in use in the domain where the application is deployed.

   Note:

   If the page does not initially display application roles, click the blue button to display all items.

2. To display application roles matching a given name, enter the data to match in the box Role Name, and click the blue button. The results of a query are displayed in the table at the bottom of the page.

   To redisplay the table of all current application policies, leave the Role Name blank and click the blue button.

3. To create an application role, click Create to display the Create Application Role page. Note that you must not enter data in all areas at once. For example, you could create a role by entering the role and display name, save your data, and later on specify the members in it. Similarly, you could enter data for role mapping at a later time.

   In the area General, specify the following attributes of the role being created:

   1. The name of the role, in the text box Role Name.

   2. The name to display for the role, in the text box Display Name.

   3. Optionally, a description of the role, the text box Description.

   In the area Members, specify the users, groups, or other application roles, if any, into which the role being created is mapped:

   1. Click Add Role, to display the Add Role dialog.

   2. In this dialog, select the type of the role to be added from the menu next to Role Type; optionally, enter a role name in the text box Role Name; and then click the blue button to display, in the box Available Roles, the roles that match the entered criteria.

   3. Select roles from the box Available Roles, as appropriate, and use the buttons in between the boxes to move them to the box Selected Roles.

   4. When finished, click OK to return to the Create Application Role page. The selected roles are displayed in the table Roles.

   In the area Users, specify the members of the role being created:

   1. Click Add User, to display the Add User dialog.

   2. The box Available Users displays all the available users. To display just the users with names matching a given string, enter that string in the box User Name and click the blue button.

   3. Select users from the box Available Users, as appropriate, and use the buttons in between the boxes to move them to the box Selected Users.

   4. When finished, click OK to return to the Create Application Role page. The selected users are displayed in the table Users.

4. Click OK to effect the role creation (or update) and to return to the Application Roles page. The role just created is displayed in the table at the bottom of that page.

To understand how permissions are inherited in a role hierarchy, see Section 3.2.1, "Permission Inheritance and the Role Hierarchy."

8.4.1.3 Managing System Policies

This section explains the steps you follow to manage system policies for a domain with Fusion Middleware Control. To manage application policies, see Managing Application Policies.

The procedure below enables creating two types of system policies: principal policies and codebase policies. A principal policy grants permissions to a list of users or groups. A codebase policy grants permissions to a piece of code, typically a URL or a JAR file; for example, an application using the Credential Store Framework requires an appropriate codebase policy.

1. Log in to Fusion Middleware Control and navigate to Domain > Security > System Policies to display the page System Policies. This page is partially shown in the following graphic:

   
   

   The area Policy Store Provider is read-only and, when expanded, displays the policy store provider currently in use in the domain.

2. To display application policies matching a given type, name, or permission, expand the Search area, enter the data to match, and click the blue button. The results of a query are displayed in the table at the bottom of the page.

   To redisplay the table of current application policies, select the type All and leave the name and permission boxes blank.

3. At any point, you can edit the characteristics of a selected policy by clicking the Edit button, or remove it from the list by clicking the Delete button.

To create a system policy:

1. Click Create to display the Create System Grant page.

2. In the area Grant Details, select type of policy to create. The valid types are Principal or Codebase. The UI differs slightly depending on the type chose. The steps below assume the selection Principal.

3. To add permissions to policy being created, click the button Add in the Permissions area to display the Add Permission dialog. In this dialog choose a permission to add to the policy being created.

   1. Use the Search area to query permissions matching a type, principal name, or permission name. The result of the query is display in the table in the Search area.

   2. To choose the permission to add, select a permission from the table. Note that, when a permission is selected, its details are rendered in the read-only Customize area.

   3. Click OK to return to the Create System Grant page. The selected permission is added to the table Permissions.

4. At any point, you can select a permission from the table and use the button Edit to change the characteristics of the permission, or the button Delete to remove from the list.

5. To add users to the policy being created, click the button Add User in the Grantee area to display the Add User dialog.

   1. Use the Search to display user names matching a pattern. The results of the query are displayed in the box Available Users.

   2. Use the buttons in between the boxes to move users from the Available Users box to the Selected Users box.

   3. Click OK to return to the Create System Grant page. The users you have selected are added to the table Grantee.

6. To add roles to the policy being created, click the button Add Role in the Grantee area to display the Add Role dialog.

   1. Use the Search to display role names matching a type or role name. The results of the query are displayed in the box Available Roles.

   2. Use the buttons in between the boxes to move users from the Available Roles box to the Selected Roles box.

   3. Click OK to return to the Create System Grant page. The roles you have selected are added to the table Grantee.

7. Click OK to return to the System Policies page. An message at the top of the page informs you the result of the operation. If successful, the policy is added to the table at the bottom of the page.

To create a system policy based on an existing system policy:

1. Select a policy from the table.

2. Click Create Like to display the Create System Grant page. Notice that some entries in the page are filled in with data extracted from the policy selected in the previous step.

3. Follow the preceding procedure (to create a system policy) to modify those values and enter new ones, as appropriate.

8.4.2.1 createAppRole

The command createAppRole creates an application role in the domain policy store with given application stripe and role name.

Script Mode Syntax

createAppRole.py -appStripe appName 
              -appRoleName roleName

Interactive Mode Syntax

createAppRole(appStripe="appName", appRoleName="roleName")

The meanings of the arguments (all required) are as follows:

• appStripe specifies an application stripe.

• appRoleName specifies a role name.

Example of Use

The following invocation creates an application role with application stripe myApp and role name myRole:

createAppRole.py -appStripe myApp -appRoleName myRole

8.4.2.2 deleteAppRole

The command deleteAppRole removes from the domain policy store the application role with given application stripe and role name.

Script Mode Syntax

deleteAppRole.py -appStripe appName -appRoleName roleName

Interactive Mode Syntax

deleteAppRole(appStripe="appName", appRoleName="roleName")

The meanings of the arguments (all required) are as follows:

• appStripe specifies an application stripe.

• appRoleName specifies a role name.

Example of Use

The following invocation removes the role with application stripe myApp and name myRole:

deleteAppRole.py -appStripe myApp -appRoleName myRole

8.4.2.3 grantAppRole

The command grantAppRole adds a principal (class and name) to a role with a given application stripe and name.

Script Mode Syntax

grantAppRole.py -appStripe appName
             -appRoleName roleName
             -principalClass className
             -principalName prName

Interactive Mode Syntax

grantAppRole(appStripe="appName", appRoleName="roleName", principalClass="className", principalName="prName")

The meanings of the arguments (all required) are as follows:

• appStripe specifies an application stripe.

• appRoleName specifies a role name.

• principalClass specifies the fully qualified name of a class.

• principalName specifies the principal name.

Example of Use

The following invocation adds a principal to the role with application stripe myApp and name myRole:

grantAppRole.py -appStripe myApp 
             -appRoleName myRole 
             -principalClass com.Example.XyzPrincipal
             -principalName myPrincipal

8.4.2.4 revokeAppRole

The command revokeAppRole removes a principal (class and name) from a role with a given application stripe and name.

Script Mode Syntax

revokeAppRole.py -appStripe appName 
              -appRoleName roleName 
              -principalClass className 
              -principalName prName

Interactive Mode Syntax

revokeAppRole(appStripe="appName", appRoleName="roleName", principalClass="className", principalName="prName")

The meanings of the arguments (all required) are as follows:

• appStripe specifies an application stripe.

• appRoleName specifies a role name.

• principalClass specifies the fully qualified name of a class.

• principalName specifies the principal name.

Example of Use

The following invocation removes a principal from the role with application stripe myApp and name myRole:

revokeAppRole.py -appStripe myApp 
              -appRoleName myRole 
              -principalClass com.Example.XyzPrincipal
              -principalName myPrincipal

8.4.2.5 listAppRoles

The command listAppRoles lists all roles with a given application stripe.

Script Mode Syntax

listAppRoles.py -appStripe appName

Interactive Mode Syntax

listAppRoles(appStripe="appName")

The meaning of the argument (required) is as follows:

• appStripe specifies an application stripe.

Example of Use

The following invocation returns all the roles with application stripe myApp:

listAppRoles.py -appStripe myApp

8.4.2.6 listAppRolesMembers

The command listAppRoleMembers lists all members in a role with a given application stripe and role name.

Script Mode Syntax

listAppRoleMembers.py -appStripe appName 
                   -appRoleName roleName

Interactive Mode Syntax

listAppRoleMembers(appStripe="appName", appRoleName="roleName")

The meanings of the arguments (all required) are as follows:

• appStripe specifies an application stripe.

• appRoleName specifies a role name.

Example of Use

The following invocation returns all the members in a role with application stripe myApp and name myRole:

listAppRoleMembers.py -appStripe myApp
                   -appRoleName myRole

8.4.2.7 grantPermission

The command grantPermission creates a permission granted to a code base or URL or principal, in either an application policy or the global policy section.

Script Mode Syntax

grantPermission [-appStripe appName] 
                        [-codeBaseURL url] 
                [-principalClass prClassName] 
                [-principalName prName] 
                -permClass permissionClassName
                [-permTarget permName]
                [-permAction comma_separated_list_of_actions]

Interactive Mode Syntax

grantPermission([appStripe="appName",] [codeBaseURL="url",] [principalClass="prClassName",] [principalName="prName",] permClass="permissionClassName", [permTarget="permName",]
[permAction="comma_separated_list_of_actions"])

The meanings of the arguments (optional arguments are enclosed in between square brackets) are as follows:

• appStripe specifies an application stripe. If not specified, then the command works on system policies.

• codeBaseURL specifies the URL of the code granted the permission.

• principalClass specifies the fully qualified name of a class (grantee).

• principalName specifies the name of the grantee principal.

• permClass specifies the fully qualified name of the permission class.

• permTarget specifies, when available, the name of the permission target. Some permissions may not include this attribute.

• permAction specifies the list of actions granted. Some permissions may not include this attribute and the actions available depend on the permission class.

Examples of Use

The following invocation creates an application permission (for the application with application stripe myApp) with the specified data:

grantPermission.py -appStripe myApp
                                -principalClass my.custom.Principal
                -principalName manager
                -permClass java.security.AllPermission

The following invocation creates a system permission with the specified data:

grantPermission.py -principalClass my.custom.Principal
                -principalName manager
                -permClass java.io.FilePermission
                -permTarget /tmp/fileName.ext
                -permAction read,write

8.4.2.8 revokePermission

The command revokePermission removes a permission from a principal or code base defined in an application or the global policy section.

Script Mode Syntax

revokePermission [-appStripe appName] 
                         [-codeBaseURL url] 
                 [-principalClass prClassName] 
                 [-principalName prName] 
                 -permClass permissionClassName
                 [-permTarget permName]
                 [-permAction comma_separated_list_of_actions]

Interactive Mode Syntax

revokePermission([appStripe="appName",][codeBaseURL="url",]
[principalClass="prClassName",] [principalName="prName",] 
permClass="permissionClassName", [permTarget="permName",] [permAction="comma_separated_list_of_actions"])

The meanings of the arguments (optional arguments are enclosed in between square brackets) are as follows:

• appStripe specifies an application stripe. If not specified, then the command works on system policies.

• codeBaseURL specifies the URL of the code granted the permission.

• principalClass specifies the fully qualified name of a class (grantee).

• principalName specifies the name of the grantee principal.

• permClass specifies the fully qualified name of the permission class.

• permTarget specifies, when available, the name of the permission target. (Note that some permissions may not include this attribute.)

• permAction specifies the list of actions removed. Note that some permissions may not include this attribute and the actions available depend on the permission class.

Examples of Use

The following invocation removes the application permission (for the application with application stripe myApp) with the specified data:

revokePermission.py -appStripe myApp
                                 -principalClass my.custom.Principal
                 -principalName manager
                 -permClass java.security.AllPermission

The following invocation removes the system permission with the specified data:

revokePermission.py -principalClass my.custom.Principal
                 -principalName manager
                 -permClass java.io.FilePermission
                 -permTarget /tmp/fileName.ext
                 -permAction read,write

8.4.2.9 listPermissions

The command listPermissions lists all permissions granted to a given principal.

Script Mode Syntax

listPermissions [-appStripe appName] 
                -principalClass className 
                -principalName prName

Interactive Mode Syntax

listPermissions([appStripe="appName",] principalClass="className", principalName="prName") 

The meanings of the arguments (optional arguments are enclosed in between square brackets) are as follows:

• appStripe specifies an application stripe. If not specified, then the command works on system policies.

• principalClass specifies the fully qualified name of a class (grantee).

• principalName specifies the name of the grantee principal.

Examples of Use

The following invocation lists all permissions granted to a principal by the policies of application myApp:

listPermissions.py -appStripe myApp
                -principalClass my.custom.Principal 
                -principalName manager

The following invocation lists all permissions granted to a principal by system policies:

listPermissions.py -principalClass my.custom.Principal
                -principalName manager

8.4.2.10 deleteAppPolicies

The command deleteAppPolicies removes all policies with a given application stripe.

Script Mode Syntax

deleteAppPolicies -appStripe appName 

Interactive Mode Syntax

deleteAppPolicies(appStripe="appName") 

The meaning of the argument (required) is as follows:

• appStripe specifies an application stripe. If not specified, then the command works on just system policies.

Example of Use

deleteAppPolicies -appStripe myApp

8.4.2.11 reassociateSecurityStore

The command reassociateSecurityStore migrates, within a give domain, both the policy store and the credential store to a target LDAP server repository. The function of this command is equivalent to reassociating domain stores with Fusion Middleware Control.

The only kinds of LDAP server targets allowed are Oracle Internet Directory or Oracle Virtual Directory. The source repository can be file- or LDAP-based. This command uses and modifies the domain configuration file jps-config.xml, and it is supported in only the interactive mode.

Before issuing this command, ensure that you have accomplished the requisites explained in Prerequisites to Using an LDAP-Based Policy Store.

An alternate way of performing reassociation using Fusion Middleware Control is explained in Reassociating Domain Stores with Fusion Middleware Control.

If this operation is to use a one-way SSL connection to the target store, follow the procedures explained in Setting Up a One- Way SSL Connection before invoking the command.

After reassociation, to secure access to the root node of the Oracle Internet Directory store, follow the instructions in Securing Access to Oracle Internet Directory Nodes.

Interactive Mode Syntax

reassociateSecurityStore(domain="domainName", admin="cnSpecification", password="passWord", ldapurl="hostAndPort", servertype="ldapSrvrType", jpsroot="cnSpecification") 

The meaning of the arguments (all required) is as follows:

• domain specifies the domain name where the reassociating takes place.

• admin specifies the administrator's user name on the LDAP server. The format is cn=usrName.

• password specifies the password associated with the user specified for the argument admin.

• ldapurl specifies the URI of the LDAP server. The format is ldap//:host:port, if you are using the default port, or ldaps://host:port, if you are using an anonymous SSL or one-way SSL transmission. The secure port must be configured to handle the desired SSL connection mode, and must be distinct from the default (non-secure) port.

• servertype specifies the kind of the target LDAP server. The only valid types are OID (Oracle Internet Directory) or OVD (Oracle Virtual Directory).

• jpsroot specifies the root node in the target LDAP repository under which all data is migrated. The format is cn=nodeName.

Example of Use

reassociateSecurityStore(domain="myDomain", admin="cn=adminName", password="myPass", ldapurl="ldaps://myhost.example.com:3060", servertype="OID", jpsroot="cn=testNode")