| |
|
Thursday, February 13, 2003
|
|
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 
|
|
Actuate
ITS is 100% committed to Actuate. We are aware of the fact that several of our customers (I can think of 4 at least) that depend on Actuate to provide mission-critical reports. We have been working on making our Actuate environement for several months now, with the ultimate objective to provide a world-class Actuate 6 environment with failover, page level security, and development, test, and production environments.
There were three major steps to upgrade to 6. First, we have to lock down our current environment. By lock down I mean restrict access to those tasked with maintaining the environment, and send all reports through acceptance testing procedures to ensure that production is not adversely affected. We have had meetings where we invited all of our customers and explained this process to them. The second step is to finalize the implementation of 6 and provide a migration path from 5 to 6. The third and final step is to move everyone off of 6 and phase out 5. Once all of these steps are completed, we will have a world-class Actuate hosting environment that will meet our customers' reliability, availability, and serviceability requirements.
Currently, we are on the first step. In order to lock down test and production, we needed to provide a development server. We have had some difficulties getting our development server to run properly, so in the meantime, developers are continuing using our test server. Project management is helping engineering and others work through the issues, and I have been in contact with customers to guarentee to them that they will always have a server to use for development. Customers with specific and unusual requirements are getting extra attention. Once we have things resolved with our development server, we will make it available to developers and let them know when the other servers will no longer be available. We will work with them to ensure they have what they need on the new development server. I don't see the process of completing step 1 lasting more than a couple of weeks. After that we move on to step 2. Also involved in step 2 is providing an Actuate 6 development environment so agencies can prepare reports for the new environment.
2:52:17 PM
|
|
Teamsite Content Management
Before reading further, please go back and review my posts from 21 and 22 January on the subject of Teamsite. They will provide you some context.
Here's the deal now:
We have been in daily contact with the vendor to gather resources and information for upgrading to version 5.5.2. I hope to have a project plan next week for installing 5.5.2. After we install 5.5.2 we have to prove that it delivers the promised features, and we have to ascertain the costs for customer provisioning, training, support, etc. I believe there could be a place for Teamsite if we can provide the environment for a reasonable price. If it is too expensive to implement for agencies, they won't use it even if we subsidize the environment. We just have to prove it out. I will have more info for you next week.
2:25:03 PM
|
|
|
© Copyright 2003 Dave McNamee.
Last update: 3/3/2003; 4:47:58 PM.
|
|
|
