Composite Roles, opinions sought.

[Former Member]

Time for a discussion on Composites. All opinions welcome

I don't believe composite roles provide a good solution to most of the problems they are used to fix

Background

Composite roles were delivered to help deploy security more quickly. Task based methodologies mean that funkies are great identifying the tasks but someone has to put them together. As one of my clients puts well: "people perform processes". Unfortunately this part is usually left until too late. It means security has to build early to stand a chance.

So they are a solution to a problem that shouldn't exist?

Yes.

Benefits?

Access represented by 1 role. Build can start earlier if there is limited input

Business can pick and choose the roles which users need to perform their role

We have a GRC solution, it is really smart so it doesn't matter what the build looks like as "the computer says yes"

Useful for creating cross system roles in a CUA master (my one situation where I find they can save time).

Drawbacks

Complexity: Change a single role and you need to analyse all the composites underneath it.

Object Duplication: The more single roles you have in a composite (or assigned to a user in general) the more authorisation duplication you have. If you have an auth value as control relevant then the more instances = more chance of a mistake.

Typically requires more role variants to give the flexibility of assignment

Alternatives

Taking the design up a level: Someone has to define jobs. A job should represent everything that a real person should be performing in SAP. Use the tasks that have been defined to get all requirements of a job & then build that as a single role.

Another approach is to build 1 role to contain all the access for a job (e.g. Accountant) and then to have an another one for "extra's" such as regional differences, special responsibilities.

Better system performance for security tasks (try reporting when you have 70000 large roles). Easier application of authorisation controls. Maintenance is easier and quicker. Fewer authorisations in the user buffer. Fewer role assignments. Quicker analysis and remediation of control issues.

Over to the floor

[Former Member]

Hello Alex,

I agree with Complexity:that if you modify a single role ,you need to anlayze in how many composite that single role exist.

But for object duplication you can minimize that if you have business process profile matrix before designing roles.

I would share my experience of designing Busniess proess profile matrix.

Thanks very much for your very useful information.

Sorry, i forgot to mention, i am learing lot of points in security after joining SDN and thanks to you and Julius and others for sharing valueble information with us

Best regards,

Prasant K Paichha

Edited by: Prasant K Paichha on Aug 27, 2009 5:25 PM

[Former Member]

Hi Prashant,

Thanks for the comments.

Maybe I didn't explain my reasoning of object duplication well. If you have 10 different FI roles then you will likely have close to 10 repetitions of F_BKPF objects for example. Can you give some guidance on how you see the business process profile matrix helping with this?

Cheers

[Former Member]

Hello Alex,

I will upload that doc and send you link here,so that you can have review and provide me feedback aboout your findings,

Business process profile is made based on users position i.e based on thier job description,and we created role as per that

It not Hr Security,its role based, that matrix will help you to determine which role user should have but giving the profile id and to which cost centre they belong.

Please let me know ,do we have any portal to upload such docs, and i do have list of use ful reports and tables which people some time ask,we can share with them .

Regards,

Prasant K paichha

[jurjen_heeck]

Personally I see great use for composite roles.

Although I agree on the duplicate object risks I think the advantages outweigh them.

If you create an authorization concept with one composite (function) role per user per system you can keep user administration relatively simple and therewith cheaper. In most companies user account changes occur far more often than function changes or other interventions within the roles. I still have to lose the first battle about composite role maintenance costs

Building a job role in one single role does not allow you to have read-rights and edit-rights with different organizational values.

Once a composite role is completely created you can run all SOD-checks on it, and if it passes, that's it, until you want to change either the composite or one of its contained singles. If you have to assign more than one role per user per system the SOD-risks and accompanying checks are shifted to user management.

Building task roles (singles) which are grouped into funcional composites allows you to build and finalize singles in an earlier stage of your project.

The bigger the singles become, the more difficult it'll be to get them signed off.

I strongly believe in task roles which can technically be used as-is so they can be tested individually.

Properly splitting tasks over different SAP modules and/or responsibilty areas also makes role ownership more transparent.

[Former Member]

I also agree on the risk factor on duplicate or shared authorization objects on simple roles within the same composite role. You can also argue that you can assign multiple single roles and it will have the same risk. Composite roles can add some complexity but it can also simplify the role assignments if the simple roles are design by jobs or tasks.

The composite roles are critical in our system environment but for a different reason. Our security is based on HR position and itu2019s also in a CUA. We use our composite role for traditional grouping of roles but more importantly to assign roles on child systems.

ECC 6.0 is our master CUA and we can only assign roles to a position that are available in ECC 6.0. You cannot assign a role in BI, SRM, SUS or other child system to a position. We use simple dummy role in ECC to point to a child role in BI, SRM, SUS, etc. We then add this dummy role to a composite role in ECC 6.0. We can then assign the composite role to a position and address the issue of assigning child roles to position. I hope that makes sense, itu2019s really simpleu2026 really

Thatu2019s it for now.

[Former Member]

I agree with Alex on all levels, but only as long as you are considering one system landscape.

if you have a setup like this (and I do):

>

> The composite roles are critical in our system environment but for a different reason.  Our security is based on HR position and itu2019s also in a CUA.  We use our composite role for traditional grouping of roles but more importantly to assign roles on child systems.

there's no avoiding composite roles, since you don't have any other technology at hand that enables you to assign roles in child systems.

[Former Member]

Hi All,

Some great comments thanks. It's good to see everyone putting their opinions forward.

I think I can see this evolving 2 ways - composites for design & composites for provisioning

Provisioning x-system & use for position based assignments looks like we have some definite advantages.

Task based design I am still not sold on, mainly due to loading costs onto the support phase rather than implementation, but I don't want to upset Jurjen's cost argument

Prasant - I'm not sure if there is a way to upload docs. Why don't you give a summary of the main points to add to the info available.

[Former Member]

> Useful for creating cross system roles in a CUA master (my one situation where I find they can save time).

Alternately you could use the IdM, where you don't need to use composites.

On the contrary, the IdM uses Business Roles which can be built using component system roles, which is much the same concept. If you still have composite ABAP roles in between, it will be a big crow's nest.

Cheers,

Julius

[Former Member]

>

> > Useful for creating cross system roles in a CUA master (my one situation where I find they can save time). 
> Alternately you could use the IdM, where you don't need to use composites.
> 
> On the contrary, the IdM uses Business Roles which can be built using component system roles, which is much the same concept. If you still have composite ABAP roles in between, it will be a big crow's nest.
> 
> Cheers,
> Julius

We still don't have IdM but it looks like a good product.

[Former Member]

I'm trying to find out if anyone uses composite roles in BI/BW 7.0 (I'll use both terms "BI" and "BW" here to mean the same thing). There is usually not a need for composite roles in BI/BW but curious if anyone has used them. Thanks.

[Former Member]

Hi David,

I have used them in the past. Same benefits/limitations as in R/3. Can be useful to consolidate report menu structures.

[Former Member]

<pre>Hi Alex,

Well this discussion could run and run, surely the use of a composite does depend on the landscape and business matter you

are trying to address?

Completely agree that with HR org. structure assignment of roles to other systems under CUA the composite role approach is

very elegant.

Globally we have a couple of views on the use of composites for 'simplifying' user access - not necessarily a position

I agree with but being out in the real world with thousands of users and roles across multiple production systems I sort of

inherited this set up. And changing something that the business perceives as not being broken, is quite hard to justify. (Happy to

take comments on why we should change this - probably a new discussion that could also run and run!)

In the US we have a pseudo IdM solution, where we have job functions made up of single roles, which if we didn't have that

solution would probably have been deployed via composites. The idea being all the access a job requires would be in the

composite role, so role allocation is easier. As it is the allocation of a job, ends up with all the single roles being provisioned to

the user master, and so from the SAP side of things there is no visibility of the job or which job each single role belongs to.

This was developed many years back before SAP moved into the IdM space and it is something the US don't want to abandon.

On the other side of the world, in our Asia Pacific systems, we don't have this set up but we do have heavy use of composite

roles, in all countries except Taiwan, who have just moved away from composites because they were too rigid.

The arguement for composites in Asia Pacific was that each composite was throughly checked against Virsa to ensure that

there were no SOD issues in the role. They also have a business direction that no user is allowed more than one composite, so

it helps ensure that users don't get SOD issues through their normal access. We still need to check for SOD but day to day role

allocations, provided they comply with the only one composite directive, should not pose risks. Does mean a bit more work on

role set up and change, but not having the automated compliant user provisioning that you could, this does help allay managment

fears that users aren't getting risky access.

For the rest of the world (EMEA and Latin America) we don't have composites much, but the desire is to deploy a global IdM

solution, so there's no business driver at the moment to deploy the US solution or the Asia Pacific solution.

Personally the cost of user role allocation support effort vs the support effort of maintaining what ever role structure is in place

is always a driver for if composites can be used - from experience security always has to play catch-up and collecting the

single roles into composites is often something that falls by the wayside.

Business roles under an IdM so that provisioning is simplified is where we'd like to get to, but the journey to get there, long and

painfull!

By the way apologies for the formatting - it looks fine in edit mode - but isn't reading any formatting when posted - sorry!

Edited by: Chris Haigh on Sep 4, 2009 1:20 PM

Edited by: Julius Bussche on Sep 4, 2009 1:30 PM

Formatting improved a little bit...</pre>

[Former Member]

HI Chris,

Thanks for your comments on the subject.

Cheers

Alex

p.s. I just remembered I have that stuff for you! will get it over.

[Former Member]

To add my 2cents to the interesting topic of composite role lets go back to the original purpose of SAP Composite role. This method is designed for an organization that has a staff performing dual or multiple job responsibilities. Instead of the potential confusion that could generate as a result of assigning volumunous single roles to a user, SAP has made it a little easier by using the composite.

You may want to ask why on earth should there not be a proper definition and assignment of responsibility, or better put, why cant an organization have one person carrying a specific job function; and my response would be most organizations are looking for a way of cutting down on resource costs therefore; they can 't afford to have one person strictly assigned to a job function. Should they be mounting so many responsibilities on one employee? No, but hey, we are not operating in the world of "what it ought to be" but "what it is." I bet you had done the same thing if you had an ownership title to a company.

Composite is good if carefully and intelligently used.

[Former Member]

True - you then also have a 1 user : 1 role mapping possibility.

But why would a user then ever need more than 1 composite role? This is seldom the case IMO. PRGN_COMPRESS_TIMES is evidence of this.

From what I have seen, composites are a "workaround" for badly built single roles (often designed too late in the project, with poor requirements) and not maintaining SU24 to keep the quality of the single roles up to scratch and intact with their menus, and consistent with some (hopefully existent) concept. Just to get the system to work... with "yellow" single roles.

Actually, an auditor once told one of my ex-boss's that benchmarking "my" systems against other SOX companies, the rest of the market is about 2 years ahead of me regarding compliance because "they" use composite roles, which means less profiles for the users, lower TCO and higher ROI etc.

What he didn't know is that my boss (the CIO) started in the company donkey's years ago as an ABAP developer, and used to drop by our office in the afternoons sometimes with a coffee - looking to see whether there was any interesting problem which needed to be debugged...

> Composite is good if carefully and intelligently used.

Composite roles are an "enabling technology": they make it possible for unsuspecting people to do stupid things beyond the bounds of that which they could achieve on their own - with single roles.

Cheers,

Julius

[Former Member]

>

> I'm trying to find out if anyone uses composite roles in BI/BW 7.0 (I'll use both terms "BI" and "BW" here to mean the same thing).  There is usually not a need for composite roles in BI/BW but curious if anyone has used them.  Thanks.

This is an interesting one. To give key users the ability to maintain their user's menu for a specific namerange of composite roles without letting them near any authorizations or the ability to assign single roles.

But there are also newer frontend components than the BEX Analyzer now - the BW Portal, WebIntelligence, BEXweb, Pioneer (a mix of BW and BO).

On the technical side, you might want to consider restricting the program ID's via which these query reports are generated and not the SAPGui menus in future. So the requirement for using composites will fall away here as well IMO.

Cheers,

Julius