Visual LANSA Forum

I am looking into the Authentication and Authorization of users in VLF-ONE with their IBM i credentials and group profiles.
I have quite a few questions regarding this, but I will try to keep it short and ask one at a time.

So, can the built-in Framework Security aka Users, Groups and Authorities be used with the iSeries user profile and group profiles with VLF-ONE?

There are some scenarios outlined in http://docs.lansa.com/14/EN/lansa048/in ... 8_2065.htm but it would appear that it is not possible with VLF-ONE (since it has a big "X" under VLF-ONE).

If that truly is not possible, then how do you handle authorization (authorities) in VLF-ONE with the iSeries?

I know about UF_OLOGON and UF_3GCHKPW, but what about the Groups and Authorities? The above link mentions creating a CL program to get the user's group profile, but then what? How do I tell the Framework that this iSeries User/Group has access to the ABC Application and the XYZ business object?

I really don't want to have to maintain two sets of users and groups and require my users to have to deal with yet another password.

Yes it works in VLF-ONE.

Setup is described here http://docs.lansa.com/14/EN/lansa048/in ... 8_6545.htm

Using groups is outlines here http://docs.lansa.com/14/EN/lansa048/in ... 8_6565.htm

Note how in the CheckUserCredentials that the user #UserProfileToCheck is input and output.

This means it can come in as FRED but be returned as CLERK_A which allows many users to be role managed as a group called CLERK_A.
The #UserNametoDisplay is used to control what is displayed.
So what started out as FRED at logon is changed to CLERK_A for authority checking and displayed as Fred Smith.

To set up and manage users from with your application you need to include some pre-shipped parts. You can see them working in the shipped demonstration in the Administration application. To add them to your own application, follow these instructions http://docs.lansa.com/14/EN/lansa048/in ... 8_6620.htm

One subtle thing to note is http://docs.lansa.com/14/EN/lansa048/in ... 8_2470.htm
This is where your own code needs to check if the current user is authorized to use business object ORDER (say).

PS1: It’s easy to lock yourself out to start, so maybe hard code your CheckUserCredentials to return #UseFrameworkObjectAuthority := false if the user profile is QSECOFR, or has IBM I admin privileges or some such thing. That allows you get in a set up basic set of users or groups.
Note how passwords are never stored in the VLF anymore – they are validated against the operating system.

PS2: Final subtlety to consider up front is found on the (Framework) -> (User Admins Settings) titled Name of User Set which is described here - http://docs.lansa.com/14/EN/LANSA048/in ... LF1935.htm

Hi Mark,

Thanks for the taking the time to explain this.

One thing that I am still not understanding however is how the users and groups get into VLF-ONE.

When I copy those "pre-shipped parts" to our framework, I now have the capability in my framework to maintain users, groups and authorities.
How then do the existing users and groups on the iSeries get into my framework? Do I recreate them in the framework, i.e. use the newly copied parts to add the same users and groups? Are they imported somehow? Is there something that I am not seeing that "automagically" pulls them in?

If the users and groups are never in the framework, then I cannot establish the authorities to the applications and objects; unless, this is where the User Authority Access Service comes into play.

Note that a VLF group is not necessarily the same as an IBM I group user, so your VLF security model does not have to be a mirror of your IBM model, it’s up to you.

First you need to decide whether you want to enrol all your user, or just create groups.

For example, If you had 20 groups on your IBM I you might only define those 20 groups into the VLF, and then use your logon program to tell the VLF what group FRED belongs to. That way you would not have to enroll FRED into the VLF model individually. You can save time initially, and later in maintenance by using a group or role based approach.

If you choose to enroll all users then you can do that manually, possibly by staging it so that end-user administrators enroll people as the need arises.

Otherwise there is a facility to mass load them available in your VLF-WIN environment, which you always have available if you are using VLF-ONE. On your (Framework) -> User Administration Settings tab you should see these two options:
The help text for those options are:
http://docs.lansa.com/14/EN/LANSA048/in ... 1_0025.htm
http://docs.lansa.com/14/EN/LANSA048/in ... 8_5670.htm
There seem to be examples of these shipped as reusable part UF_IMPUS and form UF_REPUS.
You execute them from these options on the user maintenance screen

Note how there is also an option to import users directly from an XML file available:
http://docs.lansa.com/14/EN/LANSA048/in ... f110906833

There's one final option to consider

You can replace the entire VLF security model with one of your own design. This means you never have to enroll or maintain anything in the VLF and can possibly more directly integrate with security features you might already have

Your logon program says yes or no to letting someone in, and a new VLF-ONE feature allows you to decide by using your own logic what applications, business objects and commands that someone can use.

See http://docs.lansa.com/14/en/lansa048/in ... 7_0070.htm

Note that this feature is in the EPC141017 VLF version which will be available in the next week or two I think,

There are also sometimes finely detailed authority options you may need that cannot be expressed in your right to use an application, a business object or a command.

For example, only some users might be allowed to use the Approve button on a loan details screen, or the Print button on a picking slip.

That can be handled by using custom properties. In effect you assign properties to each user “Allowed to Approve Loans” and “Print Slips” and set them to true or false. Your program code can then query those properties.

See http://docs.lansa.com/14/en/lansa048/in ... 8_0670.htm

Hey Mark,

Can't thank you enough for the info. The docs are a great reference, but I find them hard to follow when trying to put something together that I am not familiar with, which is why I really appreciate your input.

It never occurred to me that I don't need the users, to just use the groups to define the authorities. That makes a lot more sense to me.

To follow up on my understanding, please confirm or correct.

I don't need to import users I just need to create some groups and establish authorities in VLF-ONE.

I can then use the #UserProfileToCheck to authenticate against the iSeries and use the CL mentioned here to retrieve the user's group profile on the iSeries.

Then I can use that iSeries group profile to establish a "map" to the VLF-ONE group (or generic user).

Finally, I can then set the #UserNameToDisplay to the #UserProfileToCheck and then set #UserProfileToCheck to the mapped VLF group.

Now, all my authentication is handled via the iSeries and all the authorization is handled by VLF-ONE.

Everything you have stated seems okay to me.

Only think to consider is that your invented VLF groups don’t necessarily have to match with your IBM I groups.

To get the group I would be included to do something like this:
In your custom version of UF_OLOGON there is a method called Validatepassword.
Change it to also return a string parameter named #UserGroupName.
Define a char 10 field named #U3GUserGroup.
Then call your version of a CL program GETGRPPRF to get the groupd user and map it into parameter #UserGroupName.
Alternatively, you could make your own version of CL program UF_3GCHKPW and add a new parameter to it.
Also check what is returned in GRPPRF when the user is not in a group.

Sorry, I have misled you slightly in this post.
To return the user as a group user you need the just released EPC141017 VLF version.
The change is mentioned in What's New here http://docs.lansa.com/14/en/lansa048/in ... 7_0060.htm

Hi Mark,

I completely missed that. I saw the #UserProfileToCheck in the define_map and completely missed that it was for input only.

We don't have that EPC yet, will discuss with the boss about getting it.

I take it however, that is the only way to "swap" profiles, otherwise how do I tell the Framework which profile to use?

Thanks,
Joe

Yes, it is the only way that I know of because all security stuff happens on the server during login.

Yes, it is the only way to swap.