Last post May 20, 2015 02:57 PM by n2teeth
May 18, 2015 11:26 PM|n2teeth|LINK
Intranet site with Windows Authentication
Originally, our requirements were having us implement forms authentication. Our supporting database had "CreatedBy" and "UpdateById" columns on certain tables where we were tracking who created and updated records. Simply grabbing the Id of the user logged
in and inserting/update the row with the value.
Then we changed....
Now we are using windows authentication. Simple for the user; now they don't have to log in. A few questions have come up since we made this change and I haven't been able to locate other examples online.
First, should we store the username instead of an id? This would require changing all the column datatypes to string. Not a huge deal, just some overhead work. We aren't guaranteed uniqueness and there is the possibility that a user changes their username
so I can see that being an issue.
Second, is there a way to use the identity principle and peek into Active directory for the guid associated with the user. This would still require changes to the column datatypes, but would move us closer to uniqueness.
Third, is there another way that I'm not seeing? I am open for suggestions and surprised there aren't more examples online with this scenario using windows authentication. Not sure how others track changes based on the user with this security model.
Thanks in advance.
May 20, 2015 04:29 AM|Li Wang|LINK
Thank you for your post.
You could store usename and id together, when the user first login the site, you could generate a id for the user.
You could use the classes which placed in System.DirectoryServices.AccountManagement namespace to get guid of the user.
Links below is for your reference.
Hoping my reply could be helpful to you.
May 20, 2015 12:45 PM|n2teeth|LINK
Can you elaborate more on your response to question 1? I'm not following how that solution would solve the problem of username changes.
May 20, 2015 01:00 PM|PatriceSc|LINK
More likely Li Wang meant writing the guid and username inside a table. The row would be inserted or updated and ultimately it gives you an id identity value used elsewhere in your app.
In short you have a mapping table between the AD account id and your app internal id and with the username as a "cached" value.
May 20, 2015 01:04 PM|n2teeth|LINK
alright, that makes sense. seems like more overhead than what we need for less than 50 users. Especially if I can just peek into AD and get the guid.
May 20, 2015 01:16 PM|PatriceSc|LINK
You asked about question #1 but I agree, it's likely best to just embrace this change. You may still want to "cache" some AD information for example if the user name is sometime shown (not sure if CreatedBy/UpdatedBy is for internal tracking or if it is
is shown to users).
May 20, 2015 02:57 PM|n2teeth|LINK
yeah, it is just for internal tracking. Mainly just to see who did what. So I'll just change the column types to guid and retrieve the data from AD. Thanks for your input.