I'm looking to use ExAuth in my next project as there are several files and privilege sets that I wish to manage.

However, I wish to use rla to only allow a user to view/edit only the records that they create if their priv set is "User". Typically, I'd set a rule where Get(AccountName) = record's AccountCreated. However, if I use ExAuth, can I still grab an account name? If not, how do I tag the record's creator?

This solution will have a User's table (for purposes beyond account mgmt), if that impacts how I should deploy this.

I can script an Account Mgmt across multi-files, if I had to.

Suggestions?

PS: Yes, Steven, I'm reading the white paper!

Edited June 30, 200916 yr by Guest

Hi Barbara.

Yes. Once the account is externally authenticated, and the user is allowed access, using Get(AccountName) will give you the user's account name that they logged in with.

I'm reading and re-reading the callout on Steven and Wim's white paper on p.14.

Without creating accounts in the FM file, but rather creating accounts externally, I still can Get (AccountName). My worry is that I have to create two lists of identical account names, one internal and one on the Domain Controller. But that would defeat the purpose, right? So, this sounds like good news.

The only redundancy I have is the User table. I'll need that to generate staff value lists and reports by user. No biggie.

Yes I use a similar setup. Our users need to be setup with the proper group ( we used AD ) and also they need to be set up with an active user account in our local FM users table ( same reasons as you cited ).

However, the "active user account" isn't used for credentials, as I understand it. It's the account on AD that is used for credentials. You just need a user list inside FM. Right?

So, I just need to match group names and control priv sets as usual.

Thank you for your help. Hope you're around at setup, lol.

However, the "active user account" isn't used for credentials, as I understand it. It's the account on AD that is used for credentials. You just need a user list inside FM. Right?

Yup. I only have a users table in FM for value lists, local preferences, etc. Nothing to do with credentials but I do use it as an extra check because we do not want our users to access the system until they go through end user training and sometimes they have already been setup on the controller.

And of course you are welcome anytime. :

Thank you, John.

PS: End user training, what a concept! :

Edited June 30, 200916 yr by Guest

Barbara:

Just to be clear, Get(AccountName) will return whatever name the user has used as part of the credentialing process. In a domain that could be any of the following, for example:

bcooney

Barbara Cooney

barbaradomainbcooney

bcooney@barbaradomain

Whatever is a valid name in the domain.

I think we cover that in the paper.

HTH

Steven

Hey, Steven, glad to hear from you as well.

Well, I haven't met the customer's Domain Controller yet, so it's all pretty murky still. I'm imagining that I'll serve the three FM files with only a full-access account, and groups defined which map to the privilege sets I'll need.

Then, on the DC, I'll create groups with the exact same names as those in FM, as well as accounts.

The records will get a zz_AccountCreated auto-entered that equals Account Created. With that I'll set up my RLA. As long as whatever is returned is consistent and unchanging, I'll be fine.

btw, looks like I'm going to at least one day of Pause on Error. Yeah!

I'll serve the three FM files with only a full-access account, and groups defined which map to the privilege sets I'll need.

OK, just don't externally authenticate any [Full Access] accounts. That is a vulnerability you can avoid incurring.

Steven

Yes, that was in the white paper. Sounds like I've got a fair understanding, then. Thank you John and Steven.

btw, looks like I'm going to at least one day of Pause on Error. Yeah!

For those wondering about Pause on Error maybe see Pause on Error website.

Steven

John, when you say, "but I do use it as an extra check because we do not want our users to access the system until they go through end user training." What do you mean?

Do you find for that account in an Open Script, and if not found, gracefully exit and post the class schedule?

Well when working with the speed of "corporate" where IS makes their own schedules, the accounts could have already been added. However, since we do not allow users to start using the system until they have completed training, we put this additional check in. The opening script sets a few globals including account name. It checks to see if there is an existing record ( I use a relationship to check, not a find ) and also that it is active. This is so that in case someone leaves and IS drags their feet, we can at least turn off their access. Although it is not 100% secure it just adds another layer when using in conjunction with proper Acct & Privs.

If they dont have an account we show a message to contact our system admin and then it exits FM.