UMD, Authentication, Authorization, App Profile, and Identity Management
I think you can tell by the title to this post that this is no small thing. We're really talking about a major piece of enterprise infrastructure. If we do it right, this will be a huge part of almost every web application offered by the State. It is a huge part of the Governor's initiative to bring government services online.
With that said, we have languished for too long without a proper product requirements document (aka a PRD. Get used to that term because I will be using it extensively) that ties all of these interdependent systems together and describes what they will be and what they do. It's a big task, but there really is no way to separate the requirements for UMD, authentication, authorization, app profile and identity management. I will be releasing the first version of the PRD on the 26th of this month.
What follows is a brief update on each of the components of this system to tide folks over until the PRD is done.
Here is the deal with UMD: the State employee side is working with synchronization between HRE, UMD, and individual resource trees. On the public side, we pretty much have the schema determined. In other words, we know for the most part what data elements we will store for each user. However, we do not have the mechanism built yet that will migrate customer data and create new users (see identity management).
Authentication. SiteMinder 5.5 developement is moving forward. Our engineers are working through some unresolved technical issues and building the login screens.
Authorization. This is probably where most people are confused. Authorization, unlike authentication, can be implemented multiple ways. The thing to remember is that SiteMinder performs authentication and authorization every time a browser requests a protected resource. Period. That's how siteminder works. Now, you can tell siteminder to just check username and password and then do all the rest of your authorization with your application, but siteminder is still doing authorization in this case. Basically, the authorization step that it takes is to check if you are in the directory, and any member of the directory is granted access to the resource. Siteminder can do a lot more than that, and we will be articulating this fact in our PRD, so app developers know what is available and how things work. I believe we will be discovering a "most efficient" way to do authentication and authorization.
App Profile. This is the thing that allows applications to store information in the directory. It also deals with granting access to resources, and controlling the scope of administrators. App profile is where authorization information is stored. We have a very talented engineer working through the challenges associated with this problem. I would guestimate that he has about 90% of it figured out, and I gotta say I am impressed.
Identity management. Our engineers have an idea how this is going to work, but I think this one is the farthest from being figured out. More info to follow.
4:12:56 PM 
|
