4 Configuring Advanced Role-based Access Control

This chapter provides an overview to advanced role-based access control and describes the various concepts in role-based access control.

This chapter contains the following sections:

• Section 4.1, "Overview"

• Section 4.2, "Security Considerations"

• Section 4.3, "Basic Concepts"

• Section 4.4, "Access Definitions"

• Section 4.5, "Process Overview"

• Section 4.6, "Granting and Denying Permissions"

• Section 4.7, "Configuring Access Settings for Existing Roles"

• Section 4.8, "Role-based Access Control Use Cases"

4.1 Overview

Advanced Role-based Access Control, if enabled, allows organizations to limit access to and visibility of Oracle Enterprise Repository content by role at the asset and file level. This is accomplished by applying custom access settings to assets and/or files in order to limit their accessibility to particular communities of interest.

This foundational capability can be applied to a wide range of organizational initiatives:

• Exposing Web Services to customers and trading partners.

• Limiting the amount of intellectual property that is available to outsourced development teams and managing export control.

• Establishing a Federated Repository that allows everyone to view and access enterprise assets, but limits domain-specific information to users in relevant domains.

• Managing actions available to users, such as submitting, accepting, and registering assets.

• Limiting visibility of assets under development and retired assets.

• Limiting access to source code files to asset production teams.

• Granting browse-only Oracle Enterprise Repository access to selected groups.

4.2 Security Considerations

Role-based Access Control (RBAC) allows Oracle Enterprise Repository to track asset usage and production on a by-user basis, and personalizes the presentation of assets, limiting visibility to designated content in Oracle Enterprise Repository. However, Role-based Access Control is not intended to provide security for asset metadata, nor is it intended to supplement the security of underlying asset repositories.

Oracle Enterprise Repository's access settings provide no additional security for otherwise unsecured assets or data. For maximum security, asset metadata should be managed in a manner that prevents direct access to the metadata in an unsecured database. Confidential information should be embedded in the asset downloadable payload, or attached as documentation files and hosted in a secure repository.

Caution:

If you choose to circumvent an authentication and permission challenge from the underlying asset repository, you do so at your own risk.

The following actions also have security implications:

• Configuring SCM systems for access via a single Oracle Enterprise Repository user account

• Allowing system access by unapproved users

Any of these actions has the potential to open the contents of the repository to anyone with network access to Oracle Enterprise Repository.

4.2.1 Access Settings and the Asset Editor

Depending on the specific Access Settings in use, users with access to the Asset Editor may be able to see relationships to assets that are otherwise invisible to them in Oracle Enterprise Repository. In this situation, the name of the hidden asset is visible, as is the detail of the relationship between that asset and an asset to which the users have access. No other information on the hidden asset is visible in the Asset Editor. In this situation, it is possible to delete the relationship between the visible and the hidden asset. However, given that the invisible asset is inaccessible to the users in question, the relationship cannot be restored.

4.2.2 Enabling Custom Access Settings

For Oracle Enterprise Repository users, Custom Access Settings are normally already enabled and configured properly upon installation. If not, three properties must be configured in order to enable Custom Access Settings.

1. Click System Settings in the sidebar on the Oracle Enterprise Repository Admin page. The System Settings section opens in the main pane.

2. Enter cmee.customaccesssettings.enabled in the Enable New System Setting text box.

3. Click the Enable button. Custom Access Settings is displayed in the Advanced Role Based Access Control group in the Functional Settings section, as shown in Figure 4-1.

   Figure 4-1 Functional Settings

   
   Description of "Figure 4-1 Functional Settings"
   
   

4. Repeat the process to enable each of the following properties:

   • cmee.customaccesssettings.file

   • cmee.customaccesssettings.asset

   Once enabled, all three CAS system settings will appear in the Advanced Role Based Access Control group in the Functional Settings section. (Disabling any of the properties turns the feature off.)

   Note:

   If these Access Settings are not displayed in the System Settings: Access list, contact your System Administrator or Oracle Enterprise Repository Customer Support.

5. Ensure each of the settings is set to True.

6. When finished, click Save. Custom Access Settings now is displayed in the sidebar in the Admin screen, as shown in Figure 4-2.

   Figure 4-2 Custom Access Settings

   
   Description of "Figure 4-2 Custom Access Settings"
   
   

4.3 Basic Concepts

This section describes the basic concepts of Role-based Access Control. This section describes the following topics:

• Section 4.3.1, "Roles"

• Section 4.3.2, "Access Settings"

4.3.1 Roles

Within the context of Oracle Enterprise Repository, a role is defined by a specific combination of functions and responsibilities. Any given individual may have multiple roles. Access to specific assets or collections of assets, and to various Oracle Enterprise Repository features, is determined by the configuration of Access Settings for each role.

4.3.2 Access Settings

Access settings identify the functions and responsibilities that can be performed by a role. Oracle Enterprise Repository access settings fall into two categories:

• Basic Access Settings (BAS) determine the access to all assets in Oracle Enterprise Repository, and to specific tools, such as the Asset Editor. Basic Access Settings determine each user's rights to general functionality across the system. For example, a user with View permission can view all of the assets in Oracle Enterprise Repository. A user with Use and Download can download all files for all assets in Oracle Enterprise Repository.

• Custom Access Settings (CAS), if enabled, give users permission to access specific assets and files in Oracle Enterprise Repository. For example, Custom Access Settings can give a user the ability to view a specific group of assets, edit specific assets, view specific files within a particular set of assets, and so on.

All sites have Basic Access Settings enabled. Depending on your repository configuration, Custom Access Settings may be enabled.

4.4 Access Definitions

This section describes the various definitions used in Oracle Enterprise Repository. This section contains the following topics:

• "Assets"

• "Access"

• "Policies"

• "Projects"

• "Reports"

• "System Administration"

Assets

Tools regulated: Asset tab, Asset Editor, Type Manager (if enabled in your configuration of the repository).

Permission	Description	BAS	CAS
View	Access to the Asset Detail.	X	X
Use	Displays the Use/Download button in the Asset Detail.	X	X
Download	Access to file links after clicking an asset's Use/Download button.	X	X
Review	Access to Review function in the Asset Detail.	X	X
Notify	Notify subscribers about assets via ad-hoc email.	X	X
Edit	Access to the Asset Editor.	X	X
Accept	Displays the Accept button in the Asset Editor.	X	X
Approve Tabs	Displays the Approve button at the bottom of each tab in the Asset Editor.	X	X
Register	Ability to register assets via the Asset Editor.	X	X
Edit Access Settings	(CAS only) Provides the user with the ability to change CAS permissions on all assets.	X	X
Create/Submit	Ability to submit assets via the Oracle Enterprise Repository Assets screen, create new assets via the Asset Editor.	X
Launch Asset Editor	Access to the Asset Editor.	X
Edit Artifact Stores	Ability to create and edit artifact stores via the Asset Editor.	X
Edit Asset Types	Ability to configure Type metadata using the Type Manager. Requires Asset Editor permission.	X

Access

Features regulated: Admin screen: Users, Sessions, Roles, Departments, File Stores, Basic Access Settings, Custom Access Settings (if enabled in your configuration of the repository).

Permission	Description	BAS	CAS
View	View entries in the sections noted above.	X
Edit	Edit entries in the sections noted above.	X
Create	Create users, roles, departments, file stores, and custom access settings.	X
Delete	Delete sessions, roles, and custom access settings.	X

Policies

Tools regulated: Policies screen (if enabled in your configuration of the repository).

Permission	Description	BAS	CAS
Apply Policy	Allows user to apply a policy to other assets.	X

Projects

Feature regulated: Projects screen (if enabled in your configuration of the repository).

Permission	Description	BAS	CAS
View	View projects on the Projects screen.	X
Edit	Edit projects on the Projects screen.	X
Create	Create projects on the Projects screen.	X
Apply Template	Apply compliance templates to projects from the Asset Detail or the Asset Editor.	X

Reports

Feature regulated: Reports screen (if enabled in your configuration of the repository).

Permission	Description	BAS	CAS
View	Viewing reports.	X

System Administration

Features regulated: Admin screen: System Settings, Email Templates.

Permission	Description	BAS	CAS
Edit	Ability to edit general, security, authentication, and file store settings.	X
Enable	Ability to enable new general, security, authentication, and file store settings.	X

Note:

When using BAS or CAS, the following global permissions must be maintained in BAS to grant global feature permissions and functions

• Create/Submit

• Launch Asset Editor

• Edit Artifact Store

• Edit Types

4.5 Process Overview

A few simple steps allow your organization to establish a variety of security models:

• Set up roles

• Assign users to roles

• Grant permissions to roles using BAS and CAS

• Assign CAS to assets or files

Figure 4-3 describes the process overview.

Figure 4-3 Process Overview

Description of "Figure 4-3 Process Overview"

4.6 Granting and Denying Permissions

Individual users typically hold multiple Oracle Enterprise Repository Roles. For example, an individual may have both User and Registrar roles. In this case, the Registrar has permissions that are not granted to User. Similarly, an outsourced development user may have both User and Outsourced Development roles. The User role might grant access to all assets in the repository, while the Outsourced Development role denies access to any assets that have sensitive information.

When determining how to assign specific permissions to a particular Oracle Enterprise Repository user, keep in mind that permission status is divided into three levels:

• Granted

  The permission is explicitly granted.

• Not Granted

  The permission is not explicitly granted nor denied.

• Denied

  The permission is explicitly denied.

In multiple role situations, Oracle Enterprise Repository recognizes the Most Restrictive Access, that is, Denied supersedes Granted in the permission status settings. Any permission specifically Denied to a role to which a user is assigned is also denied to that user in any other role.

This section contains the following topics:

• Section 4.6.1, "Grant/Deny Access to Specific Assets"

• Section 4.6.2, "Grant/Deny Access to Specific Download Files Within an Asset"

4.6.1 Grant/Deny Access to Specific Assets

If Advanced Role Based Access Control is enabled in your configuration, then you can use Custom Access Settings to grant or deny permission to access individual assets and files. In order to create any Asset CAS, you must be assigned both the Access Administrator role and the following (BAS) permissions:

• Launch Asset Editor

• Edit Access Settings

Access to the Asset Editor and permission to edit assets is required in order to make changes to existing access settings. Oracle Enterprise Repository safeguards eliminate the possibility of locking yourself out of an asset after editing the asset's access settings (it is impossible to save such changes to the asset). However, changes to your role settings may restrict access to certain assets. Exercise caution when editing role settings.

4.6.1.1 Prerequisites

• Verify that all targeted users exist in Oracle Enterprise Repository.

• Assign global BAS permissions to each user (i.e. Create/Submit Assets, Launch Asset Editor).

If no existing role encompasses the appropriate users, one must be created. This procedure is performed on the Oracle Enterprise Repository Admin page.

1. Click Roles in the left sidebar. The Roles section is displayed, as shown in Figure 4-4.

   Figure 4-4 Roles Section

   
   Description of "Figure 4-4 Roles Section"
   
   

2. Click Create New. The Create New Role dialog is displayed, as shown in Figure 4-5.

   Figure 4-5 Create New Role Dialog

   
   Description of "Figure 4-5 Create New Role Dialog"
   
   

3. Enter the appropriate information in the Name and Description fields.

4. Click Save.

4.6.1.2 Create the Asset CAS

This procedure is performed on the Oracle Enterprise Repository Admin page.

1. Click Roles in the left sidebar. A list of available Roles is displayed in the main pane, as shown in Figure 4-6.

   Figure 4-6 List of Roles

   
   Description of "Figure 4-6 List of Roles"
   
   

2. From the list, select the role to be edited. The role detail is displayed in the bottom frame of the main pane.

3. Click the Edit button in the role detail. The Edit Role dialog is displayed, as shown in Figure 4-7.

   Figure 4-7 Edit Role Dialog

   
   Description of "Figure 4-7 Edit Role Dialog"
   
   

4. Click the Edit Users button in the Users section of the Edit Role dialog. The Add Users dialog is displayed, as shown in Figure 4-8.

   Figure 4-8 Search / Filter Users and Access Settings

   
   Description of "Figure 4-8 Search / Filter Users and Access Settings"
   
   

5. Use Search or click List All to populate the Available Users column.

6. Use the << and >> buttons to move users from the Available Users to the Selected Users column.

7. When finished, click OK. The Add Users dialog closes, and the selected users are listed in the Users section of the Edit Role dialog.

8. Click OK. The Edit Role dialog closes.

9. Click Custom Access Settings in the sidebar on the Admin screen. The Custom Access Settings section is displayed, as shown in Figure 4-9.

   Figure 4-9 Custom Access Settings Section

   
   Description of "Figure 4-9 Custom Access Settings Section"
   
   

10. Click Create New. The Create New Custom Access Setting dialog is displayed, as shown in Figure 4-10.

    Figure 4-10 Create New Custom Access Setting Dialog

    
    Description of "Figure 4-10 Create New Custom Access Setting Dialog"
    
    

11. Enter text as appropriate in the Name and Description text boxes.

12. Select Asset in the Type list.

13. Use the options in the Set Permissions section to assign relevant permissions to the appropriate roles.

    • A single click grants permission, as shown in Figure 4-11.

      Figure 4-11 Right Mark

      
      Description of "Figure 4-11 Right Mark "
      
      

    • A second click denies permission, as shown in Figure 4-12.

      Figure 4-12 Cross Mark

      
      Description of "Figure 4-12 Cross Mark"
      
      

    • A third click clears the option (permission Not Granted):

      Figure 4-13 Blank

      
      Description of "Figure 4-13 Blank"
      
      

14. When finished, click Save. The Create New Custom Access Setting dialog is displayed.

15. Click Assets in the Oracle Enterprise Repository menu bar.

16. Click Edit / Manage Assets. The Asset Editor is displayed, as shown in Figure 4-14.

    Figure 4-14 Asset Editor Window

    
    Description of "Figure 4-14 Asset Editor Window"
    
    

17. Locate and open (or create, if necessary) the asset to which the new Custom Access Settings are applied.

18. Click the asset's Administration tab, as shown in Figure 4-15.

    Figure 4-15 Administration Tab

    
    Description of "Figure 4-15 Administration Tab"
    
    

19. Use the << and >> buttons as necessary to move the new CAS from the Available to the Selected column.

20. Test the CAS by checking user permissions within and without the use case. Click the View Access button to confirm user access.

4.6.2 Grant/Deny Access to Specific Download Files Within an Asset

In order to create this or any File CAS you must be assigned the Access Administrator role and the following (BAS) permissions:

• Launch Asset Editor

• Edit Access Settings

4.6.2.1 Prerequisites

• Verify that all targeted users exist in Oracle Enterprise Repository.

• Assign global BAS permissions to each user (i.e. Create/Submit Assets, Launch Asset Editor) to allow them to submit and edit assets.

If no existing role encompasses the appropriate users, one must be created. This procedure is performed in the Oracle Enterprise Repository Admin screen.

1. Click Roles.

2. Click Create New.

3. Supply the appropriate information in the Name and Description fields in the Create New User window.

4. Click Save.

4.6.2.2 Create the File CAS

This procedure is performed in the Oracle Enterprise Repository Admin screen.

1. Click Roles.

2. Using the Edit User button in the Edit Role screen, add the appropriate users to the new role.

3. When finished, click Save.

4. Click Admin in the Oracle Enterprise Repository's menu bar.

5. Click Custom Access Settings in the sidebar on the Admin screen. The Custom Access Settings section is displayed.

6. Click Create New. The Create New Custom Access Setting dialog is displayed.

7. Enter text as appropriate in the Name and Description text boxes.

8. Select File in the Type list.

9. In the Set Permissions section, select the appropriate role(s) and assign the Download permission for this CAS.

10. Click Save.

11. Click Assets in the Oracle Enterprise Repository menu bar.

12. Click Edit / Manage Assets. The Asset Editor screen is displayed.

13. Locate and open (or create, if necessary) the asset to which the new Custom Access Settings are applied.

14. Locate the asset's File Information metadata element.

15. Select the targeted file.

16. Click the Edit button.

17. In the Custom Access Settings section of the Edit window, carefully select ONLY the new File CAS. If the targeted file does not exist, add a new file, and (in the Custom Access Settings section) select the new File CAS.

18. Click the asset's Administration tab.

19. Test the CAS by checking user permissions within and without the use case. Click the View Access button on the asset to confirm user access.

Several of the most common security use case scenarios are outlined in the sections below. Before implementing one of the new security models, however, it is necessary to configure the existing roles in your system to support Custom Access Settings.

4.7 Configuring Access Settings for Existing Roles

Oracle Enterprise Repository ships with several default roles, as defined below. When configuring Oracle Enterprise Repository for Custom Access Settings, these roles must be re-established using a combination of Basic and Custom Access Settings in order to insure that Custom Access Settings do not disrupt existing user access privileges.

4.7.1 User Roles and Default Privileges

User

Anyone with an Oracle Enterprise Repository user name and password. This role can be assigned as the default role for any new users at the time the user account is created. All Oracle Enterprise Repository users can:

• View news on the home page about the host company's initiatives

• Locate, evaluate, and use assets

• View projects (if enabled)

• Generate reports (if enabled)

• Submit assets to the registrar

Access Administrator

The Access Administrator creates all Oracle Enterprise Repository user accounts and assigns permissions. The Access Administrator must be familiar with the functions available on the Oracle Enterprise Repository Admin screen. Typically, Access Administrators can:

• Create, view, and edit users and permissions

• Generate reports (if enabled)

Advanced Submitter

The Advanced Submitter role is typically assigned to asset builders and harvesters. Asset builders focus on building the asset content base in response to organizational asset needs and the needs of individual projects. Harvesters study post-implementation projects for asset reuse potential. Typically, advanced submitters can:

• Locate, evaluate, and use assets

• View projects that are associated with assets (if enabled)

• Generate reports (if enabled)

• Submit assets to the registrar

• Edit asset metadata prior to asset registration

Registrar

The Registrar is responsible for asset acceptance or rejection and registration. There may be more than one person functioning as a repository registrar, depending on the functions addressed. Typically, registrars can:

• Locate, evaluate, and use assets

• View projects that are associated with assets

• Generate reports (if enabled)

• Submit assets to the registrar

• Edit asset metadata prior to asset registration

• Accept assets for the registration process

• Approve Asset Editor tabs

• Register assets

• Edit access settings

Registrar Administrator

The Registrar Administrator establishes and manages asset, compliance template, and policy types within Oracle Enterprise Repository using the Type Manager, if enabled in your configuration of the repository. Typically, Registrar Administrators can:

• Locate, evaluate, and use assets

• View projects that are associated with assets (if enabled)

• Generate reports (if enabled)

• Submit assets to the registrar

• Edit asset metadata prior to asset registration

• Accept assets for the registration process

• Approve Asset Editor tabs

• Register assets

• Edit access settings

• Edit Artifact Stores

• Edit Types (if enabled)

Project Administrator

If more than one default project is enabled in your configuration of the repository, then Oracle Enterprise Repository tracks asset use at the project level in order to maintain a history for maintenance purposes. Project Administrators create projects and assign users to projects using the Oracle Enterprise Repository Projects screen (visible only to users with appropriate permissions). Project Administrators also close projects and indicate which assets were deployed. Typically, Project Administrators can:

• Create, edit, and view projects (if enabled)

• Generate reports (if enabled)

System Administrator

The System Administrator configures Oracle Enterprise Repository for use. The System Administrator typically can:

• Enable and edit system settings

• Generate reports (if enabled)

4.7.2 Access Options

Two options are available for configuring access settings for existing roles, as follows. If Advanced Role Based Access Control is enabled, then access to individual assets and files can be controlled using Custom Access Settings.

• Option 1 - Access to Assets

  Grant or deny access to assets. This option is beneficial to organizations that want to use Custom Access Settings to expose a subset of assets to developers within a specific domain, to customers or trading partners, to outsourced developers, etc.

  Use Option 1 to:

  • Expose web services to customers and trading partners

  • Limit the exposure of intellectual property to outsourced development teams; manage assets that are subject to export controls

  • Establish a Federated Repository that allows everyone to view and access enterprise assets, but limits domain specific information to users representing relevant domains

  • Manage the asset life cycle by providing limited access to assets under development

  • Restrict certain groups to browse-only access to the repository

• Option 2 - File Access

  Grant or deny access to download files/payloads within an asset. This option is beneficial to organizations that use Custom Access Settings to support black box reuse. For example, developers may have access to compiled code, while asset producers and maintainers may have access to both source code and compiled code.

  Use Option 2 to:

  • Limit access to source code files to asset production and maintenance teams

The setup process is different for each option. It is easiest to start by granting or denying access to assets (Option 1), and adding file access permissions at a later time, if necessary.

Note:

Under certain access settings, asset files that are hidden from a particular user's view during the download process are visible and accessible to that same user when using the Asset Editor. In order to totally restrict that user's view of the files it is necessary to also block the user's ability to view the asset in the Asset Editor.

4.7.2.1 Option I: Grant or deny access to specific assets using CAS

Step 1 -- Re-establish default roles using Custom Access Settings.

1. Create a CAS for assets called Basic_Default_Assets.

2. Add the following roles and associated permissions to the CAS:

   • Role: User

   • Permission: View, Use, Download, Review

   • Role: Advanced Submitter

   • Permission: View, Use, Download, Review, Edit

   • Role: Registrar

   • Permission: View, Use, Download, Review, Edit, Accept, Approve Tabs, Register, Edit Access Settings

     Note:

     Under this configuration, Registrars can view and change Access Settings for all assets. To restrict this privilege, leave the Edit Access Settings option blank for the Registrar role.

   • Role: Registrar Administrator

   • Permission: View, Use, Download, Review, Edit, Accept, Approve Tabs, Register, Edit Access Settings

3. Select Automatically apply to all new assets at the top of the screen.

4. Click Save.

5. Click Yes when the Apply this new setting to all existing assets dialog is displayed. Figure 4-16 illustrates the resulting Custom Access Setting.

   Figure 4-16 Custom Access Setting Screen

   
   Description of "Figure 4-16 Custom Access Setting Screen"
   
   

Step 2 -- Enable access to Oracle Enterprise Repository Tools

1. Create the following new Roles: (include the numbers preceding the role to keep them together in the role list)

   • 1: Create/Submit

   • 2: Launch Asset Editor

   • 3: Edit Artifact Stores

   • 4: Edit Types

2. Edit current BAS settings to reflect the following:

   • Role: 1: Create/Submit

   • Permission: Create/Submit

   • Role: 2: Launch Asset Editor

   • Permission: Launch Asset Editor

   • Role: 3: Edit Artifact Stores

   • Permission: Edit Artifact Stores

   • Role: 4: Edit Types

   • Permission: Edit Types

   Remove existing BAS permissions for assets so that CAS becomes the default permission set for all assets in Oracle Enterprise Repository.

   Note:

   In order to retain global tool permissions through BAS, each user must be assigned to one of the new functional roles for each of the four previously designated functional or tool permissions, as illustrated below.

Step 3 -- Tie new roles to existing users based on existing roles

1. Edit each role and place all users who should have the ability to create/submit assets, launch the asset editor, edit artifact stores, and/or edit types, respectively, into each of the four roles.

   • Assistance Note: The following table lists the default permissions for Oracle Enterprise Repository's default roles:

   Role	Permissions
   User	Create/Submit
   Advanced Submitter	Create/Submit, Launch Asset Editor
   Registrar	Create/Submit, Launch Asset Editor
   Registrar Administrator	Create/Submit, Launch Asset Editor, Edit Artifact Stores, Edit Types

   
   

   Example 4-1 Sample Example

   Larry was previously assigned the default role User which includes the default permissions. In order to retain his existing permissions under the new settings he must be reassigned to User and also assigned to the new 1: Create/Submit role.

   Similarly, in order to retain the default permissions attached to his previously assigned Registrar role, Daryl must be reassigned to Registrar and also assigned to 1: Create/Submit and 2: Launch Asset Editor. It is also possible to add users to a role, as opposed to adding roles to users. If the default permissions for the Oracle Enterprise Repository roles are unchanged, each role can be edited to add all of the applicable users at once.

Step 4 -- Validate the changes

1. Create five users, and assign each to one of the following role combinations:

   • User, 1: Create/Submit

   • Advanced Submitter, 1: Create/Submit, 2: Launch Asset Editor

   • Registrar, 1: Create/Submit, 2: Launch Asset Editor

   • Registrar Administrator, 1: Create/Submit, 2: Launch Asset Editor, 3: Edit Artifact Stores, 4: Edit Types

   • Project Administrator.

2. Verify that each user assigned to each role listed above can see the following items:

   • User

     • Can see the Assets, Projects, My Stuff, and Reports links on the Oracle Enterprise Repository menu bar.

     • The Submit an Asset link is visible on the Assets screen. (The Edit / Manage Assets link should not be visible.)

     • A list of assets is visible after clicking the Search button on the Asset screen. The Subscribe and Use/Download buttons should be visible in each asset. (The Edit button should not be visible.) The User should also be able to post reviews.

     • After clicking the Use/Download button on an asset that includes downloadable files, the User should be able to download the files.

   • Advanced Submitter

     • Can see the Assets, My Stuff, and Reports links on the Oracle Enterprise Repository menu bar.

     • Both the Submit an Asset and Edit / Manage Assets links are visible on the Assets screen.

     • A list of assets is visible after clicking the Search button on the Assets screen. The Subscribe, Use/Download, and Edit buttons should be visible in each asset. The Advanced Submitter should also be able to post reviews.

     • After clicking the Use/Download button on an asset that includes downloadable files, the Advanced Submitter should be able to download the files.

     • Can click the Edit / Manage Assets link on the Assets screen to launch the Asset Editor.

     Verify:

     • The Approve button at the bottom of each Asset Editor tab is inactive.

     • The Register button on the Administration tab in the Asset Editor is inactive.

   • Registrar

     • Can see the Assets, My Stuff, and Reports links on the Oracle Enterprise Repository menu bar.

     • Both the Submit an Asset and Edit / Manage Assets links are visible on the Assets screen.

     • A list of assets is visible after clicking the Search button on the Assets screen. The Subscribe, Use/Download, and Edit buttons should be visible in each asset. The Registrar should also be able to post reviews.

     • After clicking the Use/Download button on an asset that includes downloadable files, the Registrar should be able to download the files.

     • Can click the Edit / Manage Assets link on the Assets screen to launch the Asset Editor.

     Verify:

     • The Approve button at the bottom of each Asset Editor tab is inactive.

     • The Register button on the Administration tab in the Asset Editor is inactive.

     • In the Asset Editor, the Accept button is visible on assets submitted via the Submit an Asset link on the Oracle Enterprise Repository Assets screen.

     • The Registrar can change an asset's access setting (if enabled in CAS).

   • Registrar Administrator

     • Can see the Assets, My Stuff, and Reports links on the Oracle Enterprise Repository menu bar.

     • Both the Submit an Asset and Edit / Manage Assets links are visible on the Assets screen.

     • A list of assets is visible after clicking the Search button on the Assets screen. The Subscribe, Use/Download, and Edit buttons should be visible in each asset. The Registrar Administrator should also be able to post reviews.

     • After clicking the Use/Download button on an asset that includes downloadable files, the Registrar should be able to download the files.

     • Can click the Edit / Manage Assets link on the Assets screen to launch the Asset Editor.

     Verify:

     • The Approve button at the bottom of each Asset Editor tab is inactive.

     • The Register button on the Administration tab in the Asset Editor is inactive.

     • In the Asset Editor, the Accept button is visible on assets submitted via the Submit an Asset link on the Oracle Enterprise Repository Assets screen.

     • The Registrar Administrator can change an asset's access setting (if enabled in CAS).

     • The Actions menu of the Asset Editor should include Configure Artifact Stores and Manage Asset Types.

   • Project Administrator

     • Can see the Assets, My Stuff, and Reports links on the Oracle Enterprise Repository menu bar.

     Verify:

     • The Submit an Asset and Edit / Manage Assets links are NOT visible on the Assets screen.

     • No search results appear after clicking the Search button.

4.7.2.2 Option II: Grant or deny access to specific files and assets using CAS

Create custom access settings that determine user access to assets, as well as to specific files within an asset.

Step 1 -- Enable all three CAS settings under System Settings

You must enable all the three CAS settings under the System Settings pane.

Step 2 -- Allow all roles that currently access the download files for all assets to get the same functionality through a File CAS

1. Create a CAS for files called Basic_Default_Files.

2. Add the following roles, each with download privileges:

   • User

   • Advanced Submitter

   • Registrar

   • Registrar Administrator

3. Select Automatically apply to all new files.

4. Click Yes when the Apply this new setting to all existing files? dialog is displayed.

Step 3 -- Allow all roles that currently access all assets to get the same functionality through an Asset CAS

1. Create a CAS for assets called Basic_Default_Assets. Add the following roles and associated permissions:

   • Role: User

   • Permissions: View, Use, Review

   • Role: Advanced Submitter

   • Permissions: View, Use, Review, Edit

   • Role: Registrar

   • Permissions: View, Use, Review, Edit, Accept, Approve Tabs, Register, Edit Access Settings

   • Role: Registrar Administrator

   • Permissions: View, Use, Review, Edit, Accept, Approve Tabs, Register, Edit Access Settings

2. Select Automatically apply to all new assets at the top of the screen.

3. Click Yes when the Apply this new setting to all existing assets? dialog is displayed.

Step 4 -- Remove existing BAS permissions for assets

CAS becomes the default set of permissions for all assets in Oracle Enterprise Repository.

Note:

In order to retain global tool permissions through BAS, each user must be assigned to one of the new functional roles for each of the four previously designated functional or tool permissions, as illustrated in Figure 4-17.

Figure 4-17 Custom Access Setting

Description of "Figure 4-17 Custom Access Setting"

1. Create four new Roles with the following names: (include the numbers preceding the role to keep them together in the role list)

   • 1: Create/Submit

   • 2: Launch Asset Editor

   • 3: Edit Artifact Stores

   • 4: Edit Types

2. Edit current BAS settings to reflect the following:

   • Role: 1: Create/Submit

   • Permission: Create/Submit

   • Role: 2: Launch Asset Editor

   • Permission: Launch Asset Editor

   • Role: 3: Edit Artifact Stores

   • Permission: Edit Artifact Stores

   • Role: 4: Edit Types

   • Permission: Edit Types

Step 5 -- Tie new roles to existing users based on existing roles

1. Edit each role and place all users who should have the ability to create/submit assets, launch the asset editor, edit artifact stores, and/or Edit Types, respectively, into each of the four roles.

   The following table lists the default permissions for Oracle Enterprise Repository's default roles:

   Role	Permissions
   User	Create/Submit
   Advanced Submitter	Create/Submit, Launch Asset Editor
   Registrar	Create/Submit, Launch Asset Editor
   Registrar Administrator	Create/Submit, Launch Asset Editor, Edit Artifact Stores, Edit Types

   
   

   Example 4-2 Sample Example

   Daryl was previously assigned the default role User, which includes the default permissions. In order to retain his existing permissions under the new settings he must be reassigned to User and also assigned to the new 1: Create/Submit role.

   Similarly, in order to retain the default permissions attached to his previously assigned Registrar role, Larry must be reassigned to Registrar and also assigned to 1: Create/Submit and 2: Launch Asset Editor.

   It is also possible to add users to a role, as opposed to adding roles to users. If the default permissions for the Oracle Enterprise Repository roles are unchanged, each role can be edited to add all of the applicable users at once.

Step 6 -- Validate the changes

1. Create five users, and assign each to one of the following role combinations:

   • User, 1: Create/Submit

   • Advanced Submitter, 1: Create/Submit, 2: Launch Asset Editor

   • Registrar, 1: Create/Submit, 2: Launch Asset Editor

   • Registrar Administrator, 1: Create/Submit, 2: Launch Asset Editor, 3: Edit Artifact Stores, 4: Edit Types

   • Project Administrator

2. Verify that each user assigned to each role listed above can see the following items:

   • User

     • Can see the Assets, Projects, My Stuff, and Reports links on the Oracle Enterprise Repository menu bar.

     • The Submit an Asset link is visible on the Assets screen. (The Edit / Manage Assets link should not be visible.)

     • A list of assets is visible after clicking the Search button on the Asset screen. The Subscribe and Use/Download buttons should be visible in each asset. (The Edit button should not be visible.) The User should also be able to post reviews.

     • After clicking the Use/Download button on an asset that includes downloadable files, the User should be able to download the files.

   • Advanced Submitter

     • Can see the Assets, My Stuff, and Reports links on the Oracle Enterprise Repository menu bar.

     • Both the Submit an Asset and Edit / Manage Assets links are visible on the Assets screen.

     • A list of assets is visible after clicking the Search button on the Assets screen. The Subscribe, Use/Download, and Edit buttons should be visible in each asset. The Advanced Submitter should also be able to post reviews.

     • After clicking the Use/Download button on an asset that includes downloadable files, the Advanced Submitter should be able to download the files.

     • Can click the Edit / Manage Assets link on the Assets screen to launch the Asset Editor.

     Verify

     • The Approve button at the bottom of each Asset Editor tab is inactive.

     • The Register button on the Administration tab in the Asset Editor is inactive.

   • Registrar

     • Can see the Assets, My Stuff, and Reports links on the Oracle Enterprise Repository menu bar.

     • Both the Submit an Asset and Edit / Manage Assets links are visible on the Assets screen.

     • A list of assets is visible after clicking the Search button on the Assets screen. The Subscribe, Use/Download, and Edit buttons should be visible in each asset. The Registrar should also be able to post reviews.

     • After clicking the Use/Download button on an asset that includes downloadable files, the Registrar should be able to download the files.

     • Can click the Edit / Manage Assets link on the Assets screen to launch the Asset Editor.

     Verify

     • The Approve button at the bottom of each Asset Editor tab is active.

     • The Register button on the Administration tab in the Asset Editor is active.

     • In the Asset Editor, the Accept button is visible on assets submitted via the Submit an Asset link on the Oracle Enterprise Repository Assets screen.

     • The Registrar can change an asset's access setting (if enabled in CAS).

   • Registrar Administrator

     • Can see the Assets, My Stuff, and Reports links on the Oracle Enterprise Repository menu bar.

     • Both the Submit an Asset and Edit / Manage Assets links are visible on the Assets screen.

     • A list of assets is visible after clicking the Search button on the Assets screen. The Subscribe, Use/Download, and Edit buttons should be visible in each asset. The Registrar Administrator should also be able to post reviews.

     • After clicking the Use/Download button on an asset that includes downloadable files, the Registrar should be able to download the files.

     • Can click the Edit / Manage Assets link on the Assets screen to launch the Asset Editor.

     Verify

     • The Approve button at the bottom of each Asset Editor tab is active.

     • The Register button on the Administration tab in the Asset Editor is active.

     • In the Asset Editor, the Accept button is visible on assets submitted via the Submit an Asset link on the Oracle Enterprise Repository Assets screen.

     • The Registrar Administrator can change an asset's access setting.

     • The Actions menu of the Asset Editor should include Configure Artifact Stores and Manage Asset Types.

   • Project Administrator

     • Can see the Assets, Projects, My Stuff, and Reports links on the Oracle Enterprise Repository menu bar.

     Verify

     • The Submit an Asset and Edit / Manage Assets links are NOT visible on the Assets screen.

     • No search results appear after clicking the Search button.

4.8 Role-based Access Control Use Cases

This section describes the role-based access control use cases.

This section contains the following topics:

• Section 4.8.1, "Use Case 1: Expose Web Services to Customers and Trading Partners"

• Section 4.8.2, "Use Case 2: Manage Intellectual Property in an Outsourced Environment"

• Section 4.8.3, "Use Case 3: Establish a Federated Repository"

• Section 4.8.4, "Use Case 4: Manage the Asset Lifecycle"

• Section 4.8.5, "Use Case 5: Limit Access to Source Code Files to Asset Production Teams"

• Section 4.8.6, "Use Case 6: Grant Browse-only Repository Access to Specific Groups"

4.8.1 Use Case 1: Expose Web Services to Customers and Trading Partners

This section describes a use case to demonstrate how to expose Web services to customers and trading partners. This section contains the following topics:

• Section 4.8.1.1, "Benefit"

• Section 4.8.1.2, "Overview"

• Section 4.8.1.3, "Solution"

4.8.1.1 Benefit

This scenario allows an organization to leverage Web Services to improve business operations between trading partners and allow its customers to connect to systems and gather information, but restricts access to information that might otherwise expose sensitive knowledge of backend systems.

4.8.1.2 Overview

In this scenario, the organization's trading partners and customers have access only to the appropriate Web Services within Oracle Enterprise Repository. Access to other assets is denied. In order to facilitate these measures, the metadata for Web service assets is organized into two general groupings:

• Unrestricted

  Metadata, associated files, and downloadable files that the organization wants to expose to all internal and external parties.

• Restricted

  Metadata, design documents, or files that reveal the inner workings of the organization's backend systems. Only internal developers will have access to this information.

The Custom Access Settings (CAS) described in this scenario provide all internal developers with access to both the restricted and unrestricted parts of Web services assets, as well as the other assets in the repository. The organization's trading partners and customers have access only to the unrestricted Web Service assets. This scenario necessitates the creation of two different Web Services asset types -- one for unrestricted data and another one for restricted data.

Note:

This scenario describes a simple way to expose Web Services to customers and trading partners. However, other considerations not addressed by this use case may require additional or alternative measures. For example, it may be more appropriate to establish a separate instance of Oracle Enterprise Repository for external use only. The external instance may be branded differently than the internal instance, and would include only the metadata, associated files, and downloadable files suitable for exposure to external parties. In this case, usage histories and reviews would reflect only the experience of external users. If your situation requires a more complex solution, please contact your Oracle Enterprise Repository Implementation Manager or Solutions Consultant for assistance and guidance.

4.8.1.3 Solution

This section describes the solution to this use case.

4.8.1.3.1 Prerequisite

Verify that Customer and Trading Partner users exist in Oracle Enterprise Repository.

4.8.1.3.2 Create and Assign the Roles

This procedure is performed on the Oracle Enterprise Repository Admin screen.

1. Click Roles. The Roles section is displayed, as shown in Figure 4-18.

   Figure 4-18 Roles Section

   
   Description of "Figure 4-18 Roles Section"
   
   

2. Click Create New. The Create New Role dialog is displayed, as shown in Figure 4-19.

   Figure 4-19 Create New Role Dialog

   
   Description of "Figure 4-19 Create New Role Dialog"
   
   

3. Enter User - Customer in the Name text box.

4. Enter Represents Web Services customers or some other descriptive text in the Description text box.

5. When finished, click Save.

6. Repeat the above process to create the role User - Trading Partner.

7. Assign the new roles to the appropriate users (i.e. user accounts representing the appropriate customers and trading partners).

   • On the Admin screen:

     • Click Roles to assign user to roles, or...

     • Click Users to assign roles to users.

4.8.1.3.3 Organize the Metadata

The metadata for Web Service assets must be organized into two general groupings according to the roles that will have Oracle Enterprise Repository access to the information. The first grouping consists of the metadata that can be viewed by everyone (Customers, Trading Partners, and Internal Developers). The second grouping consists of metadata that can be viewed only by Internal Developers.

1. Launch the Asset Editor.

2. Click Manage Types in the Actions menu. The Type Manager is displayed.

3. Use the Service asset type as a template to create a new asset type called Service - Internal Only.

4. When finished, click Save in the file menu in the Type Manager.

5. Click Copy/Migrate in the File menu in the Asset Editor.

6. Copy/migrate all existing Web Service assets to the new Service - Internal Only asset type.

7. Edit all original assets of the Service asset type to delete all metadata fields that reflect or represent information or metadata that is to be restricted from public view.

8. Delete all non-restricted fields (the first metadata grouping, as mentioned above) from the new Service - Internal Only asset type.

4.8.1.3.4 Create the Relationships

This procedure is performed in the Asset Editor.

1. Click Configure Relationships in the Actions menu. The Configure Relationships dialog is displayed.

2. Click Add.

3. Configure a two-way relationship called External-Use-Internal-Only, as shown in Figure 4-20.

   Figure 4-20 Add Relationship Dialog

   
   Description of "Figure 4-20 Add Relationship Dialog"
   
   

4.8.1.3.5 Apply the Relationship

Add the External-Use-Internal-Only relationship to the Service assets.

The procedure is performed in the Asset Editor.

1. Open one of the Service assets.

2. Click the Relationship tab.

3. Apply the External-Use-Internal-Only relationship to each Service asset. This will allow Internal Users to access the restricted fields.

4. Create a CAS.

   • Click Custom Access Settings in the sidebar on the Admin screen.

   • Click Create New.

   • Name the new CAS Access_Web_Service_Information_for_External_Use, as shown in Figure 4-21.

     Figure 4-21 Custom Access Setting: CAS Access_Web_Service_Information_for_External_Use

     
     Description of "Figure 4-21 Custom Access Setting: CAS Access_Web_Service_Information_for_External_Use"
     
     

   • Set the following permissions:

     • Role: User - Customer

     • Permissions: View, Use, Download, Review

     • Role: User - Trading User

     • Permissions: View, Use, Download, Review

5. Launch the Asset Editor.

6. Open one of the Web Service assets.

7. Select the Administration tab.

8. Apply the new Access_Web_Service_Information_for_External_Use CAS to the Web Service. This CAS will work in tandem with the Basic_Default_Assets CAS already assigned to each asset, as shown in Figure 4-22.

   Figure 4-22 Asset Editor Screen

   
   Description of "Figure 4-22 Asset Editor Screen"
   
   

9. Repeat the process with each of the Web Service assets.

4.8.1.3.6 Results

• Service Asset Type

  Figure 4-23 Service Asset Type

  
  Description of "Figure 4-23 Service Asset Type"
  
  

• Service - Internal Only Asset Type

  Figure 4-24 Service - Internal Only Asset Type

  
  Description of "Figure 4-24 Service - Internal Only Asset Type"
  
  

Note:

Note that considerably less information is provided in this view.

4.8.1.3.7 Validation Test

Select a user in each of the three designated roles and verify access as described below:

• Roles

  • User - Customer

  • User - Trading Partner

• Access

  • Only the Assets and My Stuff links are displayed in the Oracle Enterprise Repository menu bar.

  • Can see only the Web Service asset metadata intended for external view (Service Asset Type).

  • Relationships for these assets are not visible.

  • When using Web Service assets, only the primary downloadable files are available for download. No related assets are available.

  • On the Oracle Enterprise Repository Assets screen, the Submit Assets and Edit/Manage Assets buttons are not displayed.

  • The Edit button is not displayed when viewing the asset detail screen for Web Service assets.

• Role

  • User (internal employees):

• Access

  • Can see Web Service metadata intended for internal and external view (Service assets and Service - Internal Only assets).

  • Can see all relationships on Service assets.

  • If the Use/Download button is clicked when viewing a Service -Internal Only asset, files intended for external view are displayed as related assets in the download window. Both internal and external files are available for simultaneous download.

4.8.2 Use Case 2: Manage Intellectual Property in an Outsourced Environment

This section describes a use case that demonstrates how to manage intellectual property in an outsourced environment. This section contains the following topics:

• Section 4.8.2.1, "Benefits"

• Section 4.8.2.2, "Overview"

• Section 4.8.2.3, "Solution"

4.8.2.1 Benefits

The settings described in this scenario allow an organization that is operating in a highly distributed outsourced environment to manage and protect intellectual property by limiting the exposure of intellectual property to outsourced development teams. These settings also ensure that assets adhere to the limitations specified under export control regulations.

4.8.2.2 Overview

Outsourced Development Teams

In this scenario, External Service Providers (ESPs) can view, use, and provide reviews ONLY for the assets specified in their Project Profile. During the course of the project, ESPs can also submit assets produced within the project to a technical lead or Project Architect for review, approval, and asset registration. For example, after the design phase of the project, an ESP can submit the design documents for approval by the technical lead or project architect. This scenario presents a project lifecycle governance model and facilitates project milestone reviews.

Export Controls

Export control regulations typically prohibit the export of software and other types of intellectual property to certain countries. In this scenario, assets that are subject to export control are assigned a Custom Access Setting indicating that they are restricted under a specific Export Control Classification Number (ECCN). Restricted individuals are assigned a corresponding Export Control Classification Number (ECCN) role, in addition to the roles granted by virtue of their regular responsibilities as employees. For example, encryption software may not be exported to Iraq, Iran, Libya, North Korea, Sudan, Syria, or Cuba under ECCN 5D002. All encryption software assets in Oracle Enterprise Repository will receive a custom access setting Access_Restricted_by_ECCN_5D002, identifying that they are subject to export control. Individuals from Iraq, Iran, Libya, North Korea, Sudan, Syria, or Cuba will also be assigned the role User - Restricted by ECCN 5D002, indicating that they are restricted from accessing encryption software. As export control limitations change, it is easy to identify the individuals and assets affected in order to modify access settings.

4.8.2.3 Solution

This section describes the solution to this use case. This section contains the following topics:

• Section 4.8.2.3.1, "Solution for Outsourced Development Teams"

• Section 4.8.2.3.2, "Solution for Export Controls"

4.8.2.3.1 Solution for Outsourced Development Teams

The following procedures are performed on the Oracle Enterprise Repository Admin screen.

Prerequisite

Verify that External Service Providers have Oracle Enterprise Repository user accounts.

Create the Roles

1. Click Roles.

2. Click Create New.

3. Create a new role named User - ESP Project X.

   This role represents External Service Providers working on a particular project. Users in this role can view and download ONLY the assets specified in their Project Profile. They can also submit their assets to a technical lead for review, approval, and asset registration during the course of a project.

Assign the Roles

Assign the User - ESP Project X role and the 1: Create/Submit roles to the appropriate users.

The 1: Create/Submit role allows ESPs to submit assets they produce on the project to a technical lead or Project Architect for review, approval, and asset registration during the course of the project.

Click Roles to assign users to roles, as shown in Figure 4-25.

Figure 4-25 Edit Role Dialog

Description of "Figure 4-25 Edit Role Dialog"

Click Users to assign roles to users, as shown in Figure 4-26.

Figure 4-26 Users

Description of "Figure 4-26 Users"

Create the Custom Access Setting

1. Click Custom Access Settings.

2. Click Create New.

3. Create a new CAS named Access_Project_X_Assets. This CAS provides access to assets specified for use on Project X.

4. Set the following permissions, as shown in Figure 4-27.

   • Role: User - ESP Project X

   • Permissions: View, Use, Download, Review

     Figure 4-27 Edit Custom Access Settings Dialog

     
     Description of "Figure 4-27 Edit Custom Access Settings Dialog"
     
     

5. Identify the assets specified for use on Project X through the Project Profile, as shown in Figure 4-28.

   Figure 4-28 Asset Project Profile - Project X (1.0)

   
   Description of "Figure 4-28 Asset Project Profile - Project X (1.0)"
   
   

6. Add Access_Project_X_Assets CAS to the Project Profile for Project X, and to each asset specified in the Project Profile for Project X, as shown in Figure 4-29

   Figure 4-29 Custom Access Settings

   
   Description of "Figure 4-29 Custom Access Settings"
   
   

Validation Test

Verify that the following conditions for External Service Providers assigned to Project X:

• Role

  • Outsourced_Dev_User:

• Access

  • Can see the Project Profile for Project X.

  • Can see only those assets that have been specified in the Project Profile for Project X.

  • Can download the assets specified in the Project Profile for Project X.

  • The Submit Assets link is visible on the Assets screen.

  • On the asset detail display, the Subscribe and Use/Download buttons are visible; the Edit button is hidden.

  • Only the Assets and My Stuff tabs are visible in Oracle Enterprise Repository.

4.8.2.3.2 Solution for Export Controls

The following procedures are performed on the Oracle Enterprise Repository Admin screen.

Prerequisites

Verify that individuals restricted under export controls have Oracle Enterprise Repository user accounts.

Create the Role

1. Click Roles.

2. Click Create New.

3. Create a role named User - Restricted by ECCN 5D002. This role is assigned to individuals from Iraq, Iran, Libya, North Korea, Sudan, Syria, or Cuba -- any user who is to be restricted from accessing encryption software or software limited for export under ECCN 5D002.

4. Assign the new User - Restricted by ECCN 5D002 role to the appropriate users, as shown in Figure 4-30.

   Figure 4-30 Edit Role

   
   Description of "Figure 4-30 Edit Role"
   
   

Create the Custom Access Setting

1. Click Custom Access Settings.

2. Click Create New.

3. Create a new CAS named Access_Restricted_by_ECCN_5D002. This CAS restricts access to the assets specified as limited for export under ECCN 5D002.

4. Set the following permissions, as shown in Figure 4-31.

   • Role: User - Restricted by ECCN 5D002

   • Permissions: DENY access to: View, Use, Download, Review, Accept, Approve Tabs, Register, Edit Access Settings

     Figure 4-31 Edit Custom Access Setting Dialog

     
     Description of "Figure 4-31 Edit Custom Access Setting Dialog"
     
     

5. Add Access_Restricted_by_ECCN_5D002 CAS to all encryption software assets or assets restricted by export control under ECCN 5D002.

   Figure 4-32 Custom Access Settings

   
   Description of "Figure 4-32 Custom Access Settings"
   
   

Validation Test

Verify that the individuals restricted by export control limitations:

• Cannot see the assets restricted by export control limitations.

• Can see all assets not restricted under export control limitations.

4.8.3 Use Case 3: Establish a Federated Repository

This section describes the use case that demonstrates how to establish a federated repository. This section contains the following topics:

• Section 4.8.3.1, "Benefit"

• Section 4.8.3.2, "Overview"

• Section 4.8.3.3, "Solution"

4.8.3.1 Benefit

The settings described in this scenario allow Oracle Enterprise Repository users to view and access enterprise assets, but limit access to domain specific information to those assigned to the relevant domains. This allows a large organization to target specific asset consumer groups in order to provide them with the most relevant assets for their needs.

4.8.3.2 Overview

This scenario involves enterprise-wide assets that may be viewed and downloaded by anyone within the organization, and domain-specific assets that are relevant only to development teams within specific business domains. Producers of enterprise-wide assets can create, edit, and register their assets, and view and download all domain assets. Producers of domain-specific assets can create, edit, and register assets within their domain. All users within the organization may view and download enterprise-wide assets, in addition to assets that are specific to their domain.

4.8.3.3 Solution

This section describes the solution to this use case.

4.8.3.3.1 Prerequisite

Verify that enterprise and domain producers and all consumers have Oracle Enterprise Repository user accounts.

4.8.3.3.2 Create the Role

1. Click the Admin link in the Oracle Enterprise Repository menu bar.

2. On the Admin screen, click Roles

3. Click Create New.

4. Create the following roles:

   • Role: Enterprise Producer

     • Access

       Can view, download, edit, and register enterprise assets.

       Can view and download Domain assets.

   • Role: Domain X Producer

     • Access

       Can view, download, edit, and register Domain X assets.

       Can view and download Enterprise assets.

   • Role: Domain X Consumer

     • Access

       Can view and download Domain X assets and Enterprise assets.

   • Role: Domain Y Consumer

     • Access

       Can view, download, edit, and register Domain Y assets

       Can view and download Enterprise assets.

4.8.3.3.3 Create the Custom Access Settings

1. Click the Admin link in the Oracle Enterprise Repository menu bar.

2. On the Admin screen, click Custom Access Settings.

3. Click Create New.

4. Create the following Custom Access Settings:

   • CAS: Access_Enterprise_Assets

     • Allows any Oracle Enterprise Repository user to view enterprise-wide assets.

   • CAS: Access_Domain_X_Assets

     • Restricts access to Domain X assets to those assigned to the Enterprise Producer and/or Domain X Producer roles.

   • CAS: Access_Domain_Y_Assets

     • Restricts access to Domain Y assets to those assigned to the Enterprise Producer and/or Domain Y Producer roles.

   For each Domain or Enterprise asset, remove the Basic Default Assets access setting and replace it with the appropriate Custom Access Setting, as noted in Step 4, above.

   • Roles assigned to Enterprise_Producer

     Figure 4-33 Overview Section

     
     Description of "Figure 4-33 Overview Section"
     
     

   • Corresponding CAS

     Figure 4-34 Set Permissions

     
     Description of "Figure 4-34 Set Permissions"
     
     

   • Role assigned to Domain_X_Producers

     Figure 4-35 Overview Section

     
     Description of "Figure 4-35 Overview Section "
     
     

   • Role assigned to Domain_X_Consumers

     Figure 4-36 Overview Section

     
     Description of "Figure 4-36 Overview Section"
     
     

   • Corresponding CAS

     Figure 4-37 Set Permissions

     
     Description of "Figure 4-37 Set Permissions"
     
     

   • Roles assigned to Domain_Y_Producers

     Figure 4-38 Overview Sections

     
     Description of "Figure 4-38 Overview Sections"
     
     

   • Corresponding CAS

     Figure 4-39 Edit Access Settings

     
     Description of "Figure 4-39 Edit Access Settings"
     
     

5. For each Enterprise or Domain asset, remove the Basic_Default_Assets setting and replace it with the appropriate Access_Enterprise_Assets, Access_Domain_X_Assets, or Access_Domain_Y_Assets CAS, as shown in Figure 4-40.

   Figure 4-40 Asset Editor

   
   Description of "Figure 4-40 Asset Editor"
   
   

4.8.3.3.4 Validation Test

Verify the following conditions for each user/role:

• Enterprise Producer:

  • Metadata for individual Enterprise, Domain X, and Domain Y assets is visible on Oracle Enterprise Repository's Assets screen.

  • Only Enterprise assets are visible in the Asset Editor (no Asset Editor access to Domain X or Domain Y assets).

  • The Subscribe, Use/Download, and Edit buttons are visible when viewing the metadata for Enterprise assets.

  • Can edit and register Enterprise assets in the Asset Editor.

  • The Use/Download buttons are visible in the metadata display for both Domain X and Domain Y assets. However, the Edit button is NOT visible.

• Domain X Producer:

  • Metadata for individual Enterprise and Domain X assets is visible on Oracle Enterprise Repository's Assets screen; Domain Y assets are not visible.

  • Domain X assets are visible in the Asset Editor (no Asset Editor access to Domain Y or Enterprise assets).

  • The Subscribe and Use/Download buttons are available when viewing the metadata for Enterprise assets. However, the Edit button is not available.

  • Can download files from Enterprise assets.

  • The Subscribe, Use/Download, and Edit buttons are visible in the metadata display for Domain X assets.

  • Can edit and register Domain X assets in the Asset Editor.

• Domain X Consumer:

  • Metadata for individual Enterprise and Domain X assets is visible on Oracle Enterprise Repository Assets screen. Domain Y assets are not visible.

  • The Subscribe and Use/Download buttons are available when viewing the metadata for Enterprise and Domain X assets. However, in both cases the Edit button is not available.

  • Can download files from Enterprise and Domain X assets.

• Domain Y Producer:

  • Metadata for individual Enterprise and Domain Y assets is visible on Oracle Enterprise Repository's Assets screen; Domain X assets are not visible.

  • Domain Y assets are visible in the Asset Editor. However, there is no Asset Editor access to Domain X and Enterprise assets.

  • The Subscribe and Use/Download buttons are available when viewing the metadata for Enterprise and Domain Y assets. However, in both cases the Edit button is not available.

  • Can download files from Enterprise and Domain Y assets.

4.8.4 Use Case 4: Manage the Asset Lifecycle

This section describes the use case that demonstrates how to manage the asset life cycle in Oracle Enterprise Repository. This section contains the following topics:

• Section 4.8.4.1, "Benefit"

• Section 4.8.4.2, "Overview"

• Section 4.8.4.3, "Configuring the Use Case Solutions"

• Section 4.8.4.4, "Asset Lifecycle Management Solution Validation Tests"

4.8.4.1 Benefit

The settings described in this scenario allow an organization to manage assets throughout their lifecycle, from initial conception through retirement. These settings provide limited access to assets under development (assets in progress) and to retired assets. This helps to eliminate redundant development efforts by exposing assets still in development to all development teams. Development teams in need of such an asset can plan to include it in their projects, and can collaborate with the asset production team during asset development. Other settings limit the distribution of retired assets, which helps to maintain control over deployed assets.

4.8.4.2 Overview

Note:

This use case takes place against a backdrop of policies and procedures for Asset Release Management, which is focused on managing the lifecycle of assets and the artifacts that make up the assets. As part of Asset Release Management, the artifacts that make up an asset are produced by projects whose end result can be anything from the asset itself, to an entire product or system. These artifacts are harvested, along with supporting artifacts and other information, and the aggregate is packaged as an asset. Once verified as complete and correct these assets enter the repository where they are available to the entire organization. As registered assets are downloaded from the repository, defects are identified and enhancements are requested. New versions of the asset are created to address these change requests. Eventually, either through disuse or replacement by another version, an asset is retired. Retired assets are unavailable for use.

The Oracle Enterprise Repository can be used to manage access to an asset throughout its entire lifecycle, from inception through retirement. This use case focuses primarily on using Advanced RBAC to expose and to provide access to assets to different stakeholder groups throughout the asset lifecycle.

4.8.4.2.1 Asset Lifecycle Stages

• Requirements Gathering

  The organization has identified the need by several upcoming projects for a particular asset. The Production Team creates a proposed asset in progress. The metadata for this asset includes a brief description of the asset and its purpose, and is open for review and comment by a set of Subject Matter Experts associated with the relevant projects. The repository display of the asset includes a link to a dedicated virtual forum, which is used to gather functional requirements from members of the upcoming projects. The asset is visible only to those producing the asset as well as to the Subject Matter Experts on the relevant projects -- at least until the proposed asset is approved and moves to the next stage in the lifecycle, when it is visible to a wider audience.

  Note:

  Requires the Assets in Progress option for Oracle Enterprise Repository.

• Design and Development

  Once the requirements are gathered and funding for the development of the asset is approved, the producers begin generating the supporting artifacts (such as design documents and code) and associating them with the asset in the repository. At this point, only the asset's producers can add artifacts and metadata to the asset and download the asset's code. However, the asset is visible to a broader community of developers in order to allow interested parties to track its progress.

• Beta Release

  After the code has been tested it is made available as a beta release to the Subject Matter Experts representing the upcoming projects that expect to use the asset.

• Release

  Once the asset has been thoroughly tested and documented, it is made available to the entire user community.

• Scheduled for Retirement

  Once the asset has outlived its usefulness, it is scheduled for retirement. Its repository status is changed to inactive. Inactive assets remain in the repository, but access to inactive assets is limited to metadata - the asset cannot be used, and none of its files are available for download. These restrictions provide an incentive for projects to migrate to the latest version of the asset. Those responsible for managing the asset retain access to view and edit the asset until it is retired.

• Retired

  Once all projects have migrated to the new version of the asset, the repository status of the original asset is changed to retired. The asset is visible only to repository users (regardless of role) if it is related to another asset in the repository. Users may view the asset metadata through the relationship link.

This scenario describes only one of several strategies for managing access to assets in progress and retired assets. For more information about these strategies, contact Oracle Support.

4.8.4.2.2 General Configuration

The various Asset Lifecycle Management solutions described in this section require the configuration of the following roles and access settings.

(Prerequisite: Verify that the asset production teams and subject matter experts are users within the Oracle Enterprise Repository)

4.8.4.2.3 Create the Roles

1. Click the Admin link in the Oracle Enterprise Repository menu bar.

2. On the Admin screen, click Roles.

3. Click Create New.

4. Create the following roles:

   • User - Production Team Project X

   • User - Subject Matter Experts Project X

4.8.4.2.4 Create the Custom Access Settings

1. Click the Admin link in the Oracle Enterprise Repository menu bar.

2. On the Admin screen, click Custom Access Settings.

3. Click Create New.

4. Create the following Custom Access Settings:

   • CAS: Access_Project_X_Assets_Propose

   • CAS: Access_Project_X_Assets_Plan

   • CAS: Access_Project_X_Assets_Build

   • CAS: Access_Project_X_Assets_Release

The images below illustrate the detail for each role, along with the corresponding Custom Access Settings.

• Project_X_Producer: Roles

  Figure 4-41 User: Project_X_Producer

  
  Description of "Figure 4-41 User: Project_X_Producer"
  
  

• Project_X_Subject_Matter_Expert: Roles

  Figure 4-42 User: Project_X_Subject_Matter_Expert

  
  Description of "Figure 4-42 User: Project_X_Subject_Matter_Expert"
  
  

• User_Community: Roles

  Figure 4-43 User: User_Community

  
  Description of "Figure 4-43 User: User_Community"
  
  

• Asset Lifecycle Stage - Propose

  • CAS: Access_Project_X_Assets_Propose

    Figure 4-44 Edit Access Settings

    
    Description of "Figure 4-44 Edit Access Settings"
    
    

• Asset Lifecycle Stage - Plan

  • CAS: Access_Project_X_Assets_Plan

    Figure 4-45 Edit Access Settings

    
    Description of "Figure 4-45 Edit Access Settings"
    
    

• Asset Lifecycle Stage - Build

  • CAS: Access_Project_X_Assets_Build

    Figure 4-46 Edit Access Settings

    
    Description of "Figure 4-46 Edit Access Settings"
    
    

• Asset Lifecycle Stage - Release

  • CAS: Access_Project_X_Assets_Release

    Figure 4-47 Edit Access Settings

    
    Description of "Figure 4-47 Edit Access Settings"
    
    

4.8.4.3 Configuring the Use Case Solutions

The following section outlines the necessary steps for each phase of the Asset Lifecycle Management use case.

4.8.4.3.1 Requirements Gathering Stage Solution

(Prerequisite: Verify that the Asset Lifecycle Categorization taxonomy is included as part of your selected asset type.)

1. Click the Assets link in the Oracle Enterprise Repository menu bar.

2. Click Edit/Manage Assets to launch the Asset Editor.

3. Open the File menu in the Asset Editor.

4. Click New.

5. Create an asset with the initial state of Unsubmitted, as shown in Figure 4-48.

   Figure 4-48 Create a New Asset Dialog

   
   Description of "Figure 4-48 Create a New Asset Dialog"
   
   

6. On the new asset's Taxonomy tab in the Asset Editor, find the Asset Lifecycle Stages categorization.

7. Select Stage 1 - Propose.

8. On the asset's Administration tab, add the new Access_Project_X_Assets_Propose asset CAS, as shown in Figure 4-49.

   Figure 4-49 Asset Editor

   
   Description of "Figure 4-49 Asset Editor"
   
   

9. Briefly describe the asset and its purpose in the appropriate text boxes on the asset's General tab in the Asset Editor, and add a forum for use in gathering the asset's functional requirements.

10. View the asset in the Asset Lifecycle Stages categorization in Oracle Enterprise Repository, in the Stage 1 - Propose folder, as shown in Figure 4-50.

    Figure 4-50 Browse Asset Tree

    
    Description of "Figure 4-50 Browse Asset Tree"
    
    

4.8.4.3.2 Design and Development Stage Solution

1. In the Asset Editor, this asset remains in the Unsubmitted state.

2. Choose Stage 2 - Plan under the Asset Lifecycle Stages categorization.

3. Remove the Access_Project_X_Assets_Propose asset CAS and add the Access_Project_X_Assets_Plan asset CAS.

   Figure 4-51 Asset Editor

   
   Description of "Figure 4-51 Asset Editor"
   
   

4.8.4.3.3 Beta Release Stage Solution

1. In the Asset Editor, this asset remains in the Unsubmitted state.

2. Choose Stage 3 - Build under the Asset Lifecycle Stages categorization.

3. Remove the Access_Project_X_Assets_Plan asset CAS and add the Access_Project_X_Assets_Build asset CAS to the asset.

4.8.4.3.4 Release Stage Solution

1. In the Asset Editor, submit the asset. When accepted and registered by the Registrar, the asset's status changes from Unsubmitted to Registered.

2. Choose Stage 4 - Release under the Asset Lifecycle Stages categorization.

3. Remove the Access_Project_X_Assets_Build asset CAS and add the Access_Project_X_Assets_Release asset CAS to the asset.

4.8.4.3.5 Scheduled for Retirement Stage Solution

1. In the Asset Editor, change the status of the asset from Active to Inactive.

4.8.4.3.6 Retired Stage Solution

1. In the Asset Editor, change the status of the asset from Inactive to Retired.

4.8.4.4 Asset Lifecycle Management Solution Validation Tests

Confirm the following conditions for each role, as indicated:

• Role

  • Project_X_Producer

• Access

  • Has Registrar permissions throughout the lifecycle of the asset

  • Can view the asset in Oracle Enterprise Repository

  • The Use/Download and Edit buttons are visible

  • Can accept, approve tabs, register, and edit access settings for the asset in the Asset Editor.

  • In the Retired phase, the asset does not appear in the repository list of assets or searches. Repository access to the asset is possible for this role only when the asset is related to another asset, via the Relationship link. However, the asset remains accessible in the Asset Editor.

• Role

  • Project_X_Subject_Matter_Expert

• Access

  • In the Requirements Gathering phase:

    • Can view the asset, submit reviews, and subscribe to the asset (via the Subscribe button)

    • Has access to the asset's forum and may contribute comments

  • In the Design and Development phase:

    • Can view the asset, submit reviews, and subscribe to the asset (via the Subscribe button)

    • Has access to the asset's forum and may contribute comments

  • In the Beta Release phase:

    • Can view the asset, submit reviews, subscribe to the asset (via the Subscribe button)

    • Can download the asset (via the Use/Download button)

    • Has access to the asset's forum and may contribute comments

  • In the Release phase:

    • Can view the asset, submit reviews, subscribe to the asset (via the Subscribe button)

    • Can download the asset (via the Use/Download button)

    • Has access to the asset's forum and may contribute comments

  • In the Scheduled for Retirement phase:

    • Can view the asset, submit reviews, subscribe to the asset (via the Subscribe button)

    • Has access to the asset's forum and may contribute comments

  • In the Retired phase, the asset does not appear in the repository list of assets or searches. Repository access to the asset is possible only when the asset is related to another asset, via the Relationship link. The asset will display the same functions/permissions as are listed in the Scheduled for Retirement phase.

• Role

  • User_Community

• Access

  • In the Requirements Gathering phase:

    • Has no access to the asset.

  • In the Design and Development phase:

    • Can view the asset, submit reviews, and subscribe to the asset (via the Subscribe button)

    • Has access to the asset's forum and may contribute comments

  • In the Beta Release phase:

    • Can view the asset, submit reviews, subscribe to the asset (via the Subscribe button)

    • Has access to the asset's forum and may contribute comments

  • In the Release phase:

    • Can view the asset, submit reviews, subscribe to the asset (via the Subscribe button)

    • Can download the asset (via the Use/Download button)

    • Has access to the asset's forum and may contribute comments

  • In the Scheduled for Retirement phase:

    • Can view the asset, submit reviews, subscribe to the asset (via the Subscribe button)

    • Can download the asset (via the Use/Download button)

    • Has access to the asset's forum and may contribute comments

  • In the Retired phase, the asset does not appear in the repository list of assets or searches. Repository access to the asset is possible only when the asset is related to another asset, via the Relationship link. The asset will display the same functions/permissions as are listed in the Scheduled for Retirement phase.

4.8.5 Use Case 5: Limit Access to Source Code Files to Asset Production Teams

This use case is somewhat similar to Use Case #1 (Web Services). That use case used two different asset types for each Web service asset in order to manage the presentation and availability of internally-exposed and externally-exposed asset metadata. Use Case # 5 also involves the restriction of access to asset metadata and files, but relies on only one asset type.

This section contains the following topics:

• Section 4.8.5.1, "Benefit"

• Section 4.8.5.2, "Overview"

• Section 4.8.5.3, "Solution"

4.8.5.1 Benefit

The settings described in this scenario facilitate black-box reuse by limiting the access of certain users/roles to assets that include compiled code. Such black-box assets are used as-is, without modification to the source code. Black-box assets are high-value assets in that their use in projects generally results in significant maintenance savings.

4.8.5.2 Overview

In this scenario, developers in specified asset consumer roles are limited to access to compiled code only, while those responsible for the production and maintenance of assets retain access to both source and compiled code.

4.8.5.3 Solution

This section describes the following use cases:

4.8.5.3.1 Create the Roles

1. Click the Admin link in the Oracle Enterprise Repository menu bar.

2. On the Admin screen, click Roles.

3. Click Create New.

4. Create the following roles:

   • Production Team

   • Maintenance Team

   • Consumer

4.8.5.3.2 Create the Customer Access Settings

1. Click the Admin link in the Oracle Enterprise Repository menu bar.

2. On the Admin screen, click Custom Access Settings.

3. Click Create New.

4. Create the following Custom Access Settings:

   • Access_Domain_X_Compiled_Code_Files

     • For users who can see compiled code files.

   • Access_Domain_X_Source_Code_Files

     • For users who can see sourced code files.

5. Remove the Basic_Default_Files CAS from the targeted assets. (This assumes that the Default File CAS has been set up.), as shown in Figure 4-52.

   Figure 4-52 Edit Dialog

   
   Description of "Figure 4-52 Edit Dialog"
   
   

6. Assign the Access_Domain_X_Compiled_Code_Files CAS to all compiled code files, as shown in Figure 4-53.

   Figure 4-53 Edit Dialog

   
   Description of "Figure 4-53 Edit Dialog"
   
   

7. Assign the Access_Domain_X_Source_Code_Files CAS to all source code files.

Figure 4-54, Figure 4-55, Figure 4-56, Figure 4-57, Figure 4-58, and Figure 4-59 illustrate the Production Team, Maintenance Team, and Consumer roles, and the relevant CAS settings respectively.

• Production_Team (all production users): Roles

  Figure 4-54 User: Production_Team

  
  Description of "Figure 4-54 User: Production_Team"
  
  

• Maintenance_Team (all maintenance users): Roles

  Figure 4-55 User: Maintenance_Team

  
  Description of "Figure 4-55 User: Maintenance_Team"
  
  

• Consumers (all consumers): Roles

  Figure 4-56 User: Consumer

  
  Description of "Figure 4-56 User: Consumer"
  
  

• Access_Domain_X_Compiled_Code_Files

  Figure 4-57 Custom Access Setting

  
  Description of "Figure 4-57 Custom Access Setting"
  
  

• Access_Domain_X_Source_Code_Files

  Figure 4-58 Custom Access Setting

  
  Description of "Figure 4-58 Custom Access Setting"
  
  

4.8.5.3.3 Results

Production Team, Maintenance Team, and Consumer users see the same metadata information when viewing the asset in Oracle Enterprise Repository, as shown in Figure 4-59.

Figure 4-59 Asset: Sample Component

Description of "Figure 4-59 Asset: Sample Component"

Production Team and Maintenance Team users see both the compiled and source code files during asset download, as shown in Figure 4-60.

Figure 4-60 Use / Extract Dialog

Description of "Figure 4-60 Use / Extract Dialog"

Consumers see only the complied code file during asset download, as shown in Figure 4-61.

Figure 4-61 Use / Extract Dialog

Description of "Figure 4-61 Use / Extract Dialog"

4.8.5.3.4 Validation Test

Verify the following conditions for each role.

• Production_Team and Maintenance_Team:

  • Both source and compiled code files should be visible after clicking the Use/Download button.

  • The Edit button should be visible when viewing the asset in Oracle Enterprise Repository.

• Consumer

  • Only compiled code files are visible after clicking the Use/Download button.

  • The Edit button does not appear on assets for which the Consumer has access to compiled code only. If the Consumer has edit permission for assets containing source code, the source code files are visible to the Consumer in the Asset Editor.

4.8.6 Use Case 6: Grant Browse-only Repository Access to Specific Groups

This section describes the use case that demonstrates how to grant browse-only repository access to specific groups. This section contains the following topics:

• Section 4.8.6.1, "Benefit"

• Section 4.8.6.2, "Overview"

• Section 4.8.6.3, "Solution"

• Section 4.8.6.4, "Validation Test"

4.8.6.1 Benefit

The settings described in this scenario allow control over the rollout of the Repository within an organization by providing everyone with browse-only Repository access. This is helpful when promoting Repository use to a large group of development teams. Additional access can be assigned as necessary to the appropriate roles by the Access Administrator, as determined by organizational policy.

4.8.6.2 Overview

In this scenario, all Repository users are automatically assigned browse-only access. It is likely that users are authenticated against LDAP, and will gain access to the Repository using their standard organization-assigned login user name and password. As these users determine their need for additional functionality, they can be assigned additional roles by Repository administrators.

4.8.6.3 Solution

This section describes the solution for this use case.

1. Create the following role:

   • user - browse only

2. Ensure that this role is automatically assigned to new users, as shown in Figure 4-62.

   Figure 4-62 Edit Role: user-browse only

   
   Description of "Figure 4-62 Edit Role: user-browse only"
   
   

3. Edit the User role to ensure that it is not automatically assigned to new users, as shown in Figure 4-63.

   Figure 4-63 Edit Role: user

   
   Description of "Figure 4-63 Edit Role: user"
   
   

4. Edit CAS: Basic_Default_Assets.

   Figure 4-64 Edit Custom Access Setting: Basic_Default_Assets

   
   Description of "Figure 4-64 Edit Custom Access Setting: Basic_Default_Assets"
   
   

   • Click the Show all available roles option to see the full list of available roles.

   • Assign View access to user - browse only by checking the appropriate box.

   • Save the CAS.

4.8.6.4 Validation Test

Add a new user to the system:

• Verify that the new user is assigned browse-only privileges:

• Can view and subscribe to all assets

• Can access My Stuff

• Cannot submit assets

• Cannot download assets

• Cannot review assets