Authority List - Question / Query

[Brian B]

I?ve used AUTL to secure objects since I started out donkey?s years ago. I think I understand the concepts and the rules but then every now and again I get an authorisation issue which seems to break the rules.
The problem I get every now and again is that the Authority List rules break down and I am forced to put the profile into the user authorities of the object which has an AUTL list named. The authorities appear to ignore the fact that the object is secured by an authorisation list, but I don?t know why.
In this instance, the user was authorised to the object via several routes, due to a supplemental Group Profile owning the object (I know bad practise and once I wouldn?t use personally, just haven?t gotten around to fix this legacy set-up), and the same supplemental profile being authorised in the Authorisation List (*ALL) yes again lazy set-up seeing as this is a program object, and additional supplemental groups also being listing in the Authorisation List.
Basically when does the entry of the Authority List in the object authority get ignored ?
Do I have to specify Public *AUTL , to ensure the settings in the AUTL are followed, currently Public *Exclude with the authorised users specified (as Groups) in the AUTL ?

[jtaylor___]

AFAIK, you have to set "*PUBLIC *AUTL" for that list to be enforced.

[john.sev99]

IBM has a flowchart of the authority checking steps that it follows, if you can follow it you should be able to work out what's happening. You should be able to search for authority checking flowchart in the infocentre to locate it.
I don't agree with jtaylor - you don't need to specify *PUBLIC *AUTL in my experience. As far as I'm aware that just says the public authority is as specified in the AUTL.
I don't know why authorising an object by group profiles is a bad idea? Group profiles are checked before authorisation lists so in theory would be quicker to check, though in practice with todays systems I doubt it would make any real difference. Group profiles are normally setup based on users roles and objects given the appropriate authorities for that role. It's a perfectly acceptable means to authorise objects.

[tomliotta]

I mostly agree with john.sev99, but there's no real answer possible without knowing the actual relationships among the user profile, the group profiles, the private object authorities on the object and the *AUTL entries.

The How the system checks authority topic in the Knowledge Center should provide needed detail and examples.

[Brian B]

IBM has a flowchart of the authority checking steps that it follows, if you can follow it you should be able to work out what's happening. You should be able to search for authority checking flowchart in the infocentre to locate it.
I don't agree with jtaylor - you don't need to specify *PUBLIC *AUTL in my experience. As far as I'm aware that just says the public authority is as specified in the AUTL.
I don't know why authorising an object by group profiles is a bad idea? Group profiles are checked before authorisation lists so in theory would be quicker to check, though in practice with todays systems I doubt it would make any real difference. Group profiles are normally setup based on users roles and objects given the appropriate authorities for that role. It's a perfectly acceptable means to authorise objects.

Thank you for pulling me up on the Group Profile thing, I see re-reading it how it could be misunderstood. Authorising an object by group profile isn't a bad idea, I didn't explain it properly. In the case above the set up is such that the profile owning the objects is the profile that users are grouped too and so inherit their authority from. So the Group Profile is the object owner, this is what I was saying wasn't the best idea, basically because the object has all authority to the object by virtue of owning it, in the majority of instances the profiles don't need *ALL authority. I usually set up a separate ownership profile for environments that is not a group profile, so it is a stand alone profile not used to sign on or group users too. When using group profiles I have the group profile authorised appropriately to need, or users role. I didn't mean to say that it was a bad idea to authorised an object by group profiles. Yes I was aware the AUTL is checked after Group Profiles but as said todays servers are so much faster that I also doubt it would be an issue.