OpenId Part Three: Authorization
Posted by: Clarity Blogs: ASP.NET,
on 04 Sep 2009 |
View original | Bookmarked: 0 time(s)
As promised in part two, Ill close the loop on OpenId by talking briefly about authorization. Weve already seen how to authenticate, so once youve got an authenticated OpenId identifier, the trick is what to do with it. This does not end up being all that exciting; in my case linked back to an identifier column in my user table and to get information about the newly logged in user. Based on characteristics of that user, I could then determine their authorization level or roles. Stick the roles into the FormsAuth cookie in pipe delimited list and you can then write code like this in your controller action:
public ActionResult Edit(long id)
if (!User.IsInRole(UserRoles.CRUD)) return View("AccessDenied");
So going from authentication to authorization is not that big of a jump. Where it gets a little trickier is what I glossed over before, going from the OpenId identifier to the user. In an open, public site where you want as many to create accounts as possible this association can be created as part of new account set up.
When the site is meant to mostly private or internal, you dont just want anyone creating accounts with privileges to modify or access your data. Our solution was to set up users in the database, but leave the OpenId identifier blank. We then had a special url where we could point the actual user to go and register their OpenId identifier with the unclaimed user account. This still doesnt feel quite right to me, but it is workable for small, internally addressed sites. It was nice to work with OpenId and the excellent DotNetOpenAuth library, but overall it seems that OpenId fits more naturally for a public-facing, community oriented site.