Under the Covers with NWBC #4 – No Authorisation
That last one was a doozie, probably time for our hero Bob to take a break and sort out an easy one. This one is much more simple; Alice is getting an authorisation issue when she tries to create a new customer. She can see the entry in her NWBC menu but when she clicks on it she gets a an authorisation error. Never fear Alice… Bob’s got this one covered too.
Key Learnings
Well if you’re a security or BASIS administrator then that probably wasn’t anything new to you, if you come from a portal background or are new to all this then maybe it was. So while not the most complex problem to solve it does bring up an interesting question… Do you split your roles into Menu Roles and Authorisation Roles? Doing so certainly has it’s advantages and disadvantages, I’m in favour of having separate menu roles to aid maintenance (imagine having your menu scattered across 100s of potential security roles, being managed by multiple people). I’d be interested to hear how you manage your roles, please comment below if you’d like to share.
There’s one more challenge left for Bob before he can pack up and head home Under the Covers with NWBC #5 – Respond to SAP Support
HI Simon
When I started an implementation I went in with the attitude of (1) Avoid Composite Roles and (2) do not do menu only roles. So my position was No - don't split the roles out
Menu only roles would require dual maintenance as each time you make a role change and increase the risk of authorisation error in NWBC. For those from a SAP Security background there is increased chance that someone would maintain the authorisations for the menu roles. If not, SUPC reports will flag the role as red.
The entire NWBC layout approach was designed on single template nwbc roles. When transactions and objects are added to a menu they are always added to the single role and then copied to the end user roles to have consistent layout. This way, any settings on invisible/bold/rename description is the same across all roles
Our training team could then have the template assigned to do their recording and users get the consistent navigation (even though they may not see all the links). In this case, it's a training client so we have split menu from authorisations.
Most of my design as around ensuring the SSM_CUST table merged duplicate folders/menus and then drive all security build from normal PFCG menu. Combination of single roles will result in users's access
However, the major short coming is the merging of menu. Unlike Portal, I cannot control the sort order of each transaction/folder/object in my PFCG menu when items merge. Sure I can do some overall menu tweaking via the PFCG menu options I can enter the sort/merge like I could in Portal.
Anyway, my thoughts are now starting to go towards composite roles. The only reason I"m considering this is we have use business roles. Each user only has one business role which is a container of single. If I build the composite menu it overcomes the merge (assuming no user is special)
If SAP could only add additional attributes into PFCG and allow us to control the sort sequence then I wouldn't have a problem. I've seen the NWBC ideas blog in SCN and it's been on the list.
So pretty please SAP, allow us to have a sort order field in PFCG menu like we did in Portal.
I don't really agree with this as the alternative (as I mentioned above) is one team making NWBC look good and the security team not getting the memo to update authorisations. This was always a challenge with Portal build and backend.
But it may come down to the complexity of your system - how many users, roles and administrators as well as how many systems are connected into NWBC.
Regards
Colleen
P.S. on the simulation when you mentions it's an auth only role it might have been worth showing how you have hidden the menu in NWBC and/or SAP GUI.
Hi Colleen,
Thank you for your great comment (it is longer and more detailed than my original post) 😀
I totally agree with you regarding the limitations on sorting and merging in the NWBC menus, and really hope that SAP can provide more control in the future.
With regards to splitting menu roles or not I am still not 100% convinced either way and like you say it will depend on your circumstances. One thing I have done in the past which eases maintenance is to create a master menu and a program to auto-magically create menu roles based on the master menu and what t-codes the user actually has authorisation for (I have to thank John Moy for that idea). This allows us to maintain the menu structure in a single place (the master menu role) and have it cascade out to all other business roles.
Thanks again for your interest and the time you've taken to comment.
Cheers,
Simon
Hi Simon
I say John's presentation of their NWBC design and he mentioned the program. I was under the impression some of this design had integration with BPMLs in Solution Manager
I would love to implement something similar but the overhead to get development budget in security is a challenge at many client sites. For a lot of companies, NWBC does negate need for a portal but to then need to develop your own tools isn't 'simple'
Technical aside, you then have a major discipline on the architecture and process design to automate this.
However, if you could implement such a thing then splitting roles would not be as bad as you're not dual maintaining and you're adhering to strict design rules.
Regards
Colleen