portalroles.pdf

8/17/2019 portalroles.pdf

http://slidepdf.com/reader/full/portalrolespdf 1/59

Setting Up PortalRoles in SAPEnterprise Portal 6.0

Julia Levedag, Vera GutbrodRIG and Product Management

SAP AG



SAP AG 2003, TechED_Basel / Session PRTL-255, Levedag/Gutbrod / 02.10.03

Learning Objectives

As a result of this workshop you will

be able to:

Understand the Concept of Portal Roles

Administer Roles and other Portal Content

Define Portal Navigation

Learn about the Context of Roles and Permissions

Understand the Concept of Delegated Administration




Agenda

Introduction of Role Concept

Roles and Content Objects

Role Maintenance

Navigation and User Assignment

Permissions vs. Authorizations

Permissions and Delegated

Administration




Role Concept: Why Create Roles?

Role 2Role 1

User 1Group 1 Group 2

Content 1 Content 5Content 3Content 2 Content 4

Only by creating roles are you able to assign different pieces of content

to different groups of users.




Role Management: Examples

Customer Credit

Manager

Project Leader

Market Analyst

One enterprise portal to cover di fferent user roles

One enterprise portal to cover di fferent user roles




What are Portal Roles?

A role is a container for appl ications and

information that can be assigned to aparticular group of users.

The content of a role enables users to perform

the tasks in their respective job description.

The content of a role is based on the company

structure and on the information needs of the

portal users in the company.

The portal navigation structure is defined bythe sum of the roles assigned to the user.

Technically, a role is a hierarchy of folders

containing other portal content objects.

Roles can be assigned to users or groups of

users, i.e. the portal role connects users (or

groups of users) to the portal content.

User Group 2

Role A

User Group 1

Role Assignment




What are Worksets?

A role usuall y consists of one or moreworksets that bundle applications andinformation.

A workset is a co llection o f applicationsand information that belong together froma semantic point of v iew because they arepart of the same activi ty area (e.g.controll ing or budgeting) of a user.

Whereas a role is based on g lobalcompany structures, a workset is based onuser-specific tasks or activities (for

example, “My Budget” or “ My Staff” areworksets in the “ Manager” role).

Worksets are building blocks for roles:One workset can be used within severalroles, and one role can consist of severalworksets.

Technically, a workset is a hierarchy of folders that contains other portal content

objects. Worksets cannot be assigned to users

(only roles can be assigned to users).

Workset A

Role 1 Role 2

Workset Assignment




Relationship Between Roles and Worksets: Example

Sales Manager

Team

Lead

Key

Account

Manager

Promotion

Manager

Market

WatchBudget

Role

Worksets

Monitoring

Planning

App roving

Forecasting

Activity assignmentHiring

Communication

Sell productsImprove relationships

Send product

information

Track order fulfillment

Negotiate

Monitor/analyze keyfigures

Watch competitors

Create sales/

promotion strategies

Explore market

Create promotionsRun promotions

Track status

Analyze impact

Activities




Roles, Users and Content

User 1 User 2

Assignment Assignment

Role A Role B Role CRole D

Role E




Portal Roles and SAP Roles

Concept of roles and worksetsConcept of single and composite

roles

Carrier of the navigation information

for the portal user

Carrier of author ization profile

information

Classif ication of users according to

information needs

competence and responsibility

Classification of users according to

task

authorization

Based on the structure of the

company and the information needed

by the users

Based on user tasks in a SAP

system; relevant for creation of the

role-based SAP Easy Access Menu

Independent of application; contain all

kinds of information (heterogeneouscontent): SAP and non-SAP

applications, documents, Internet and

Intranet in formation

Depend on SAP component (FI, BC

etc.); content of a SAP role alwaysrefers to a certain SAP system

Portal RolesSAP Roles




Summary

Portal roles define

the content and tasks that a user can access in the portal

how the user can access the content (=navigat ion opt ions in

the portal)

Note: Portal roles have no effect on authorizations in the backend

system.




Agenda



Role Maintenance




Administration




Portal Content Directory (PCD)

The Portal Content Directory (PCD) is the central persistence store for all portal

objects. This includes, for example, storage of the metadata for the content

objects (roles, worksets, etc.) and the relationship between the objects.

Portal Content

(Portal Content

Directory)

Roles

Pages

iViews

Worksets




iViews and Pages on the Portal Desktop

A portal page is a container for

different iViews.




Roles

Roles are the largest

semantic units wi thin

content objects.

They include folder

hierarchies consist ing

of folders, worksets,

pages and iViews.The role structure also

defines the navigation

structure of the portal.

Roles are assigned to

users.

iViews and

Pages

WorksetRole

Folder Page iView




Agenda



Role Maintenance




Administration




Portal Catalog and Portal Content Studio

All content objects (li ke roles, worksets, iViews, and pages) are available

in the Portal Catalog and are maintained in the Portal Content Studio:

The Portal Content Studio provides a central

environment for developing and managing portal content,

including iViews, pages, layouts, worksets, roles and

transport packages.

The Portal Catalog

provides a central

access point to all

portal content

objects stored in

the PCD. It permitsyou to store,

manage and

organize content in

a structured

hierarchy.




Creating Roles (1)

In the content administration role, choose Content Administration -> Portal Content.

You create roles by clicking

the right mouse button. The

wizard for creating

new roles is started.




Creating Roles (2): Role Wizard

Enter general propertiesfor the new role.

Enter the folder for storing

the new role in the Portal Catalog.

Check all properties. The

new role is created and is now visible

in the Role Editor.




Creating Roles (3): Role Editor

Create the role hierarchy

and add content objects

(roles, worksets, pages,

iViews) to the role as

delta link.

Change the properties in

the Property Editor

(optional)

You create worksets in the same way as roles.

For worksets, use the Workset Editor.




Roles and Worksets as Containers of Other Objects

Roles and worksets are created by:

Building structural hierarchies

Adding content objects to these hierarchies

Objects that can be added to a role: ro les, worksets, iViews, pages

Objects that can be added to a workset: worksets, iViews, pages

Page 1

Workset 1

Role 1

Role A

Delta link

Delta link

Delta link

iView 1Delta link

Role 1

Workset 1

Page 1

iView 1

add as

add as

add as

add as

Objects are added to

roles and worksets as

delta links.




Delta Links

Al l content objects can be related to each other us ing delta links.

A delta link is a relationsh ip between two objects (source and target

object) of the Portal Content Directory. The source object is theobject that passes its property values to a target object that is

derived from the source object (=principle of inheritance of

properties).

Delta links allow you to change the target objects, that means

additions, deletions and changes to property values and structure

hierarchies. Thus delta links are valid for st ructural hierarchies (for

example in roles and worksets) and properties values (for example iniViews and pages).

Changes made to the source object are copied to the target object

and are visible there. Changes made to the target object have no

effect on the source object. Source objects are protected against

modifications.

Workset 1 Workset 2

Structure

Properties

Structure

Properties

Delta link

Source object Target object




Creation of Portal Roles: Summary

1. Log on as super administrator or

content administator.

2. Open Portal Catalog.

3. Create new role.

4. Specify storage of role.

5. Add objects to role.

6. Define entry points.

7. Save.

Portal Catalog

Role Wizard

Role Editor




Agenda



Role Maintenance




Administration




Roles and Worksets Define he NavigationalStructure of SAP Enterprise Portal

Top-Level Navigation

Detailed Navigation

Portal content (pages and iViews) can be navigated by clicking

entries in the top-level navigation and/or detailed navigation.

The navigation entries are derived from the structures of roles

and worksets. The administrator defines which nodes of a role

or workset should be visible as navigation entries for the user

of the portal.




Top-Level Navigation and Entry Points

Entry points: these are the nodes

in a role or workset structure that

are defined as tabs (entry poin ts)

for top-level navigation.




Defining Entry Points

In the Role Editor: Click on a role node in the rolestructure and define it as the entry point.

Entry points are highlighted in the role structure.




Detailed Navigation

Everything in the role structure that ison the third level and lower appears

in the detailed navigation.

First level (= entry point)

Second level of top-level navigation

Third level (inside detailed

navigation)




Role Assignment to Users/User Groups

In the user administration role, choose User Administration -> Role Assignment.

1. Select the users and groups to which you want to assign a role. Search for the roles

and add them to the selected user or group:

2. Select the roles to which you want to

assign a user or group. Search for the

users and groups and add them to the

selected roles:




Agenda



Role Maintenance




Administration




Portal Permissions

Portal permissions define the access rights of por tal users to portal

objects. Permissions in the portal are based on access cont rol lis t

(ACL) methodology.

By defining permissions, you enable the delegation of administrative

tasks and content in the portal environment.

Objects in the Portal Content Directory (PCD) have two sets of

permissions: administrator and end user. This distinct ion is

necessary to contro l what an administrator sees in the portal

administration environment (at design time) and what is seen in theend user environment (at runtime).

Note: Permiss ions in SAP Enterprise Portal are not authorizations in the

backend system.




Portal Roles vs. Authorizations

EnterprisePortal

SAPSystems

Enterprise Apps

CMSystems

Others

Role

Definition

Role

Definition

Authorizations Authorizations

No maintenance of authorizations for

SAP systems in SAP Enterprise Portal.

Author izations are st il l maintained in

the SAP system.




Portal Roles and Authorizations in SAP Systems

Portal ro le in

SAP Enterprise Portal

Portal role in

SAP Enterprise Portal

Authorization role

in the SAP system

Author ization role

in the SAP system

Portal Roles Author ization Roles

Contain transactionsfrom different SAP systems

Contain transactionsfrom different SAP systems

Export / Distribution

Author ization ro les are created in theSAP systems and assigned to users.

Author izat ions are st il l maintained wi th

Transaction PFCG

Author izat ion roles are created in theSAP systems and assigned to users.

Authorizations are st il l maintained wi th

Transaction PFCG




Agenda



Role Maintenance




Administration




Roles & Permissions

A typical use case to understand the context of roles and

permissions is to understand the principles of delegated

administration.

Roles will provide the assigned users wi th content.

Permissions in the portal context will provide access to content

objects stored in the Portal Content Directory:

Administ rators:

With ACLs access to any object in the Portal Catalog is defined for

administrators. End Users:

With ACLs access for end-users is defined – content structures within

the Portal Catalog are visible; iViews can be executed by end users or

not.




Delegated Administration

Delegated Administration needs to be realised to distribute

administration tasks within a complex organisation.

That means you have to distribute and controle...

Administration and Maintenance of content like portal roles

Administration and Maintenance of system configuration like UM

configuration, monitoring configuration, service configuration, etc.

Administration and Maintenance of user information (e.g. Users,

Groups, User-Role Assignment, ...)

Delegated Administration is realised by different portal tools like

Predefined customizable administration roles

ACLs on fo lder hierarchies in the portal content catalog

User Admin permissions on the User Administration role




Delegated Administration: Business Scenario

I. Create a system ABC

II. Create iView for system ABC

III. Assign iView to page/ role

IV. Assign Role to users

Delegation of tasks

System „ ABC“ iView „ ABCiview“ page/role assignment user-role assignment

Definition of ACLs for the di fferent administration v iews

of portal content catalog necessary!

System Administrator Content Administrator Content Administrator User Administrator

Roles




Concepts – Delegated Administration

Delegated Administration

How to define access

to PCD objects?

Who is administrator?How to put PCD objects

in the right order?

Create organisational

tree for administrators

Define permissions

on folders and objects

Define folder structure for

Portal Catalog

How to establish an administration process among different administrators?




Preconfigured Administration Roles

access on all tools for user administration to create and maintain users,

administrate the role-user assignment, user mapping administration, user

Replication, Group administration, etc.

User

Administrator

access on all tools for system administration such as system configuration,

transports, permissions, monitoring, support, portal display

access on all parts of tree hierarchy of Portal Content Catalogs if the right

Acls have been defined

System

Administrator

access on all Content Administration tools for creation of roles, worksets,

pages, iViews, layouts

access on all editors to maintain content e.g. Permission Editor, Property

Editor

access on all parts of tree hierarchy of Portal Content Catalog if the right

ACLs have been def ined

Content

Administrator

assigned to init ial SAP* User

„ Full Control “ access on whole Portal Content Catalog Tree

Access on al l admin tools

of Content Adminis trator Role

of System Administrator Role

of User Admin istration Role

Super

Administrator

FunctionRole




Admin Roles and Portal Catalog Objects

Content administrators areresponsible for content objects

in the Portal Catalog. ACLs def ine the access and

allowed action for contentobjects like folders, roles,worksets, pages, iViews andtemplates.

System administrators are

responsible for systemadministration tasks andobjects.

ACLs def ine the access andallowed actions for objects liketransport packages or systems.

User administrators are

responsible for users relatedtasks.

Role-User Assignment can becontroll ed by permissions setfor user management role.

Super admin

Content admin 1

Content admin 2

Content admin 3

System admin 1

System admin 2

System admin 3

User admin 1

User admin 2

User admin 3

+ ACL

+ ACL

+ ACL

+ ACL

+ ACL

+ ACL

Set Action

Set Action

Set Action




Designtime Permission (Administration)

Administ rator Permissions

Check during creation

process for objects

Check when accessing

objects

Worksets

Pages

Systems

Folder & objects

visible Edit object properties

Edit assigned delta

links

Edit permissions

Delete objects

Create fromTemplates with

READ permission

OWNER

Folder & objects

visible

Edit object properties

Edit assigned delta

links

Delete objects

Create from

Templates with

READ permission

FULL

CONTROL

Folder & objects

visible

Edit object properties

Edit assigned delta

links

No delete!

Create from

Templates with

READ permission

READ/

WRITE

Folder & objects

visible

Copy objects

No Edit

Create from

Templates with

READ permission

READ

Folder & objects notvisible

Folder & objectsnot visible

NONE

Edit ObjectsCreate/ Delete

Objects

ACL Check

on Folder

Level and on

Object Level

Portal Catalog




Runtime Permissions (End User)

End User Permissions

Check for Navigation

Check for in Personalize

Page Component

Check i f calling component

via URL

Worksets

Pages

Systems

Direct access to an iView – USE

permission is required

Direct URL access to a

component: Users may accessportal components through URL

without an intermediate iView if

they are granted USEpermission in the appropriate

security zone.

User Interfaces inthe end user

environment thatdisplay the portal

content catalog

(such as personalize

page) only di splay

objects that have

end user permission.

Navigation iViews (TLN, detailednavigation, Drag&Relate targets,

related links) only display rolesand objects that have end-user

permission.

For display of objects in

navigation the ACL is checked

on the object l evel.

USE

PersonalizationNavigation

ACL Check

on Folder

Level and on

Object Level

Personalize Page




Example: Delegated Content Administration *

Editing

Edit_1

Editor_A => includes all objects of area edit_1

such as iViews, pages, worksets and roles

Portal Content

iViews

Pages

Worksets

Roles

Editor_B => inc ludes all objects of area edit_1

News

Knowledge

Portal

Personalization

Administrator Ressources

A al l = READB all = READ

User A = FULL CONTROL

User B = READ

User A = FULL CONTROLUser B = None

User C = WRITEPublic

Templates

User A = FULL CONTROL

User B = Read

* View of a Portal Adminis trator on the Portal Catalog!




Example: Delegated System Administration

System Administrators have access to different views of the

Portal Catalog.

The role „ system administrator“ comprises several tools to

access objects like

Transport Packages – stored in the Portal Catalog

Permissions – to be maintained through the Portal Catalog

System Landscape Objects - to be defined in the Portal Catalog.

Access to several portal objects is limi ted to the ro le system

administrator.

Access to certain folders and objects for users with role „ system

administrator“ will be defined via ACL.




Delegated System Administration – Transport

When creating

transport

packages toexport content

READ/WRITE

access is

required on a

particular folder.




Delegated System Administration – Export

When definingcontent to be

included into atransport package ACLs are checkedas follows:

Only objectscan be includedif as a minimumREADpermission for the object isgiven.

During exportdependingobjects are onlyincluded if the

request user has READpermission for them.




Delegated System Administration – Import

A user assigned to the system administrator role can import any

packages stored in the import directory.

The import into the Portal Content Directory can only be done if the reuqest user has READ/WRITE permission to any folder in

which the transported object needs to be stored.




Delegated System Administration – Create Systems

For creating a

new system the

request user needs to have the

following ACLs:

READ/WRITE

for the folder in

which the

system objectwil l be created

READ for the

system

template on

which the

object is based




Delegated System Administration – Create Systems

When creating a system

object based on a template

at least READ permission isrequired for the request

user.

The permission needs to be

defined for the template

object.

A system administ rator may

only create systems but

cannot define an iView

pointing to that system. To

do so the content

administrator role is

needed.




Delegated Administration – Systems & iViews

To create an iView based

on that system it is

necessary to beassigned to the content

administration role.

The content

administrator therefore

needs READ permissionfor the system to create a

working iView based on

the system object.




Example: Delegated User Administration

Delegated user administration allows you to distr ibute user administration between several administrators so that each

administrator is responsible for a particular set of users.

For Delegated User Admin istration you have to distinguishbetween

Overall User Administ rators can add, modify and delete users of allcompanies. They can create and administer delegated user administrators and assign them appropr iate roles and permissions.

In addition the following tasks can only be performed by an overalluser

Group Management

Role Management

User Mapping

Import and Export of user data

Replication of user data

Delegated User Administrators can add, modify and delete users thatbelong to the same company as the delegated user administrator.




Delegated User Administration – Company Concept

Delegated User Administration based on company concept:

A company is a set of users

User administ ration can be done per company, by a company

administrator for all the users within that company

1.

2.

3.




Permissions assigned to User Administration Role

A combinat ion of the permiss ions of Full User Administration and Full ACL

Administ rat ion.

By default, this action is assigned to the Super Administration role only.

Full User

Administration,Full ACL

Administration

Any ro le to which thi s ac tion is ass igned has Owner permissions on all

objects i n the Portal Content Catalog.

It is not possible to remove this permission in the permission editor. Thisaction is designed for super administrators that are not responsible for overall

user administration.

Full ACL

Administration

Contains permission required by an delegated user administrator:

Administ rat ion of users belonging to t he same company as the

administrator

Role assignment: Permissions to assign roles to users belonging to the

same company as the administrator. No permissions to assign roles togroups.

Delegated User

Administration

Contains permissions by an overall user admin:

Administ rati on of users belonging to any company and poss ib il ity of

assigning users to co mpanies

Group management Role assignment

User mapping

Import and export of user data

Manual replication of user data

Full user administration

Configuration of Delegated User Administration using




Configuration of Delegated User Administration usingCompanies

1. Define the required companies

2. Create a role for delegated user administrators

3. Enable “Check ACL” for Role Assignment Component

4. Assign appropriate properties to delegated user administration ro le

5. Define one or more delegated user administrators for each company

6. Assign users to companies us ing options l ike

• Overall user administrator uses administration console

• User is registered via approval workflow

• Overall user administrator uses user import function and use theOrg_ID attribute to assign a company to users

If the company concept is enabled, the list of users for role

assignment is limited




Create Delegated User Administrator Role

Create a different

User

Adminis trators UserAdmin_1

Add the or iginal

user

administrator role

per delta link to anew role

Assign the role

user_admin




Enable „Check ACLs“ for Role Assignment

For iView com.sap.portal.roleAssignment enable

property “ CheckACL = true”




Define Permission for delegated user admin role

The role for the

Delegated User

Adminis tratorsneeds to be

edited:

Change property

„ User Admin

Permission“ toDelegated

Administ ration.




Summary

Roles define what content can be seen by the end user/administator.

Roles are a standard portal feature for structuring content for user

groups and/ or single users. Roles define how content is represented at the user’s desktop.

Roles and navigation st ructures are closely interrelated.

Roles can be used as containers for portal content.

Portal content is provided by content objects such as worksets, pages

and iViews. It becomes available to users by assignment to roles.

Roles connect the portal user with the content. Roles can be assigned to users or user groups.

Roles and portal content need to be combined with permissions.

Access Contro l Lists (ACLs) def ine what content can be seen by which

administrator.

ACLs def ine what content the end user can execute.

Portal roles do not contain authorizations for SAP systems. Author izations for SAP systems are maintained in the SAP system.



No part of this publication may be reproduced or transmitted in any form or for any purpose without the express

permission of SAP AG. The information contained herein may be changed without prior notice.

Some software products marketed by SAP AG and its distributors contain proprietary software components of other

software vendors. Microsoft®, WINDOWS®, NT®, EXCEL®, Word®, PowerPoint® and SQL Server ® are registered trademarks of

Microsoft Corporation.

IBM®, DB2®, DB2 Universal Database, OS/2®, Parallel Sysplex®, MVS/ESA, AIX®, S/390®, AS/400®, OS/390®,

OS/400®, iSeries, pSeries, xSeries, zSeries, z/OS, AFP, Intelligent Miner, WebSphere®, Netfinity®, Tivoli®, Informix

and Informix® Dynamic Server TM are trademarks of IBM Corporation in USA and/or other countries.

ORACLE® is a registered trademark of ORACLE Corporation.

UNIX®, X/Open®, OSF/1®, and Motif ® are registered trademarks of the Open Group.

Citrix®, the Citrix logo, ICA®, Program Neighborhood®, MetaFrame®, WinFrame®, VideoFrame®, MultiWin® andother Citrix product names referenced herein are trademarks of Citrix Systems, Inc.

HTML, DHTML, XML, XHTML are trademarks or registered trademarks of W3C®, World Wide Web Consortium,

Massachusetts Institute of Technology.

JAVA® is a registered trademark of Sun Microsystems, Inc.

JAVASCRIPT® is a registered trademark of Sun Microsystems, Inc., used under license for technology invented

and implemented by Netscape.

MarketSet and Enterprise Buyer are jointly owned trademarks of SAP AG and Commerce One.

SAP, R/3, mySAP, mySAP.com, xApps, xApp, SAP NetWeaver and other SAP products and services mentionedherein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and in

several other countries all over the world. All other product and service names mentioned are the trademarks of

their respective companies.

Copyright 2003 SAP AG. All Rights Reserved

Documents

portalroles.pdf