AUT parm on user profile

[J.Pluta]

AUT parm on user profile

Off the top of my head, Susan, I suspect that the answer is that it is an additive situation: you'll get the sum of all the authorities in the profiles. This is because, from reading the security manual, what the system does is first check and see if the user profile has authority, then checks the authority list for the object, the checks to see if the group profile has authority, then checks the supplemental groups. If any of these have enough authority for the requested operation, the operation is allowed. Now, that's from reading the manual (specifically the OS/400 Security Reference), so of course the best bet would be to actually try it. I'll do that when I get a chance, but don't hold your breath . src="//www.zappie.net/java/_derived/index.htm_cmp_zero110_vbtn_p.gif" width="140" height="60" border="0" alt="Java400.net - Java/400 Freeware" align="middle"> Java400.Net - where the AS/400 speaks Java with an RPG accent Home of PBD2.0, the color=red>FREE Java/400 Client/Server color=blue>Revitalization Toolkit

[J.Pluta]

AUT parm on user profile

Ah hah! A little further digging uncovered THIS nugget:

| 5.6.5 Supplemental Group Profiles | A supplemental group profile is another type of group profile on the | system. A user profile can reference up to fifteen additional group | profiles that will be used to check authorities. In checking authority, | the user will be granted access to an object if at least one of the user's | supplemental group profiles have access to the object, and the specified | user does not have a private authority to the object that would not allow | access. Supplemental group profiles are specified in the user profile. | Use the CHGUSRPRF command to add them.

This is from, of all things, the OV/400 manual. The url is: http://publib.boulder.ibm.com/cgi-bi...QBKAWW00/5.6.5 To my reading, that means if you don't have specific private authority to the object, it uses the sum of the group profiles. This is further expanded upon here: http://publib.boulder.ibm.com/cgi-bi...QBKAWW00/5.6.3 Hope this helps, Susan. src="//www.zappie.net/java/_derived/index.htm_cmp_zero110_vbtn_p.gif" width="140" height="60" border="0" alt="Java400.net - Java/400 Freeware" align="middle"> Java400.Net - where the AS/400 speaks Java with an RPG accent Home of PBD2.0, the color=red>FREE Java/400 Client/Server color=blue>Revitalization Toolkit

[nycsusan@hotmail.com]

AUT parm on user profile

Thanks for taking the time to look this up, Joe! I interpret this to mean if you are a member of ANY supplemental group with sufficient authority to perform whatever action, you will be allowed - unless specifically excluded from doing so. I hope that I am understanding this correctly. If I am, things sure are going to change 'round here! Interesting. We have conflicting group authority out the wazoo here, and that's why this topic is of particular interest to me. Good information - thanks again for ferreting it out.

[nycsusan@hotmail.com]

AUT parm on user profile

Ooops, I forgot to ask ...Does the fact that one group is your primary group matter? Or will the system treat the primary group the same as your secondary groups for purposes of allowing access? I didn't see anything in those IBM pages that differentiated between primary and secondary groups for access privileges.

[J.Pluta]

AUT parm on user profile

Yeah, I think you have it right, Susan. Again, I suggest you check it out, but at least you now have a starting point. (BTW, don't blow my cover... I'm actually the ferret on the Budweiser commercials.) Joe

[J.Pluta]

AUT parm on user profile

No, you did ask, I just didn't answer it very well: to the best of my knowledge, the system treats all 16 groups (your group profile and 15 supplemental group profiles) the same, except that it checks your group profile authority first. Note: there is a small but real performance issue with this scheme. As you add more groups, it will take a few more cycles for the system to determine a user has no authority. Similarly, if the system has to check 15 group profiles before determining that you are authorized, that will add cycles. However, judicious selection of the group profile and proper order of the supplemental groups should help you to minimize any performance impact. src="//www.zappie.net/java/_derived/index.htm_cmp_zero110_vbtn_p.gif" width="140" height="60" border="0" alt="Java400.net - Java/400 Freeware" align="middle"> Java400.Net - where the AS/400 speaks Java with an RPG accent Home of PBD2.0, the color=red>FREE Java/400 Client/Server color=blue>Revitalization Toolkit

[Guest.Visitor]

AUT parm on user profile

Joe, Now I have a homework project. What I will look into is whether you can dynamically obtain supplemental group authority by swapping profiles. The problem with obtaining authority directly using supplemental group profiles is that that you cannot control the access method to an object. For example, if I assign a programmer to a group like PAYROLL, he will have all access to payroll and I have no control over how he accesses the information. This means he could accidentally use CPYF to overlay the production data and will most likely have to have two profiles. By using adoption I prevent access from anything but authorized interfaces (no one making copies to diskettes, file transfers, etc.) David Morris

[nycsusan@hotmail.com]

AUT parm on user profile

This helped. Thank you, Joe.

[J.Pluta]

AUT parm on user profile

Very good point, David. If you have the ability to programmatically restrict access to the data, adoption is by far the best technique. Let's look at the alternatives:

1. In the days of green screens and no command lines, a combination of public authority, restricted user profiles and menu option authorization worked quite nicely. Users can't get to command lines, so can't do any damage. This is the way, for example, MAPICS works.
2. Next stage, we have to give the users the command line (for whatever reason). Now we have to restrict access. Well, we say "Exclude 'em ALL!" and user adopted authority to provide access. Again, a nice thing, provided users have no access to the command line while inside an adopted program (although I think there are limitations on carrythrough these days).
3. Now we enter the PC era. Users demand access to "their" files from their PC (for things like Access and Excel). In this case, the users have to actually have access to their files at "all" times. This is where group profiles come in. You must logically group access to files into groups (yes, I'm from the Department of Redundancy Department), then add all those groups to the user profile as needed.

And therein lies the rub. What if, for applications, the user needs write access to a file, yet for some ad hoc queries, needs only read access? Is there a way to somehow switch the user from one set of authority to another? Well, in fact there are several options:

1. One user profile, with read-only capabilities, and adoption of write capabilities within the production programs. This allows queries, but not updates, from the PC.
2. Two user profiles, one read-only, one with write capabilities. The write-capable profile is restricted and can only be used to call production programs. The read-only profile is used for distributed database queries.
3. Again, two profiles, but perform a user-profile swap automatically within the production programs. The only benefit over option B. is that the users don't even know about the phantom user profile, and it doesn't need signon capabilities.

One thing about having a read-only user profile: from what I understand, you might even be able to assign column-level (field-level) security for this user profile (that is, disallowing access to certain fields in a file), but I'm not certain. Anyway, these are just a few ruminations, David. Perhaps they'll help you think the problem through. src="//www.zappie.net/java/_derived/index.htm_cmp_zero110_vbtn_p.gif" width="140" height="60" border="0" alt="Java400.net - Java/400 Freeware" align="middle"> Java400.Net - where the AS/400 speaks Java with an RPG accent Home of PBD2.0, the color=red>FREE Java/400 Client/Server color=blue>Revitalization Toolkit

[Guest.Visitor]

AUT parm on user profile

Joe, I believe the way to achieve column level security is to create a LF that explicitly lists the fields that users should see and give the LF object *PUBLIC authority of *USE. Then change the PF authority to just *READ and *EXECUTE. When you don't give the user *OPR authority to a file, the user cannot open the PF directly. But in this case the user can open the LF. Ultimately, the data authorities within a LF are controlled by the data authorities on the PF (you could give the user *CHANGE authority to the LF but really the user still just has *READ, *EXEC). Both the PF and LF in my example have *READ, *EXEC but only the LF has *OPR. Application programs in this setup need to adopt authority too to users can still update the files through a controlled means. Chris

[Guest.Visitor]

AUT parm on user profile

Joe, Thanks for taking the time to point out some of the ramifications and options of the various authority schemes. The main point in revisiting our authority structure at this point is that our current structure does not encompass exit programs, IFS files, and, as you pointed out, limitations on carrythrough. The main advantage of the system we have today is simplicity. There is a single level of authority assigned to all objects, and a single program obtains the necessary rights. This program is used at the various entry points to our applications. With just a few exceptions, authorities match library authorities, and each person has a single profile. It looks like some complexity needs to be added in order to address exit points and the IFS. One other important aspect of security is ensuring data integrity. Triggers and constraints are a tools that can help. Because constraints are so limiting, we decided to place triggers and validations on all files. You can also use a trigger to further restrict authority. Thanks, David Morris