Hi Scott, It looks like the support for WS-Trust and ActAs is the main update. Is that correct? I think that is a good change, which I hope all the stacks can support. Do we need to take a vote on that?
Regarding the choice below, I like the interoperable one. However, I don't quite understand the following: >> The advantage of the interoperable approach is that several passive STS >> users could map to a single active STS user. I think even if we go with interoperable, that we should still have a one-to-one mapping of end user to uid. Are you saying I might be a customer at three different banks that all provide trading through the same broker and so I would have a single account at the broker? Or are you just saying there would be a single service account representing each bank, and it would use the ActAs claim to connect to the end-user's data? Kent -----Original Message----- From: Scott Golightly [mailto:[email protected]] Sent: Thursday, July 02, 2009 12:58 PM To: Stonehenge Development Subject: Claims based authentication I just uploaded changes to my proposal based on feedback I got from some identity experts who are not part of the Stonehenge project. Again the document is in Word and PDF format to provide the broadest distribution possible. If we as a group can agree in principle that we want to change the application to used claims based security then we need to decide on the next level of detail. I see this as needing to start with two decisions that will then guide the rest of the implemenation. The first and most fundamental question is if we want the identity providers to be interchangeable or interoperable. Currently all implementations are using the same data in the database so logging in to the applicaiton with user name 'uid:0' and password 'XXX' returns the same data regardless of which front end, business service, and database. We can continue doing that and determine a set of values for the passive STS that any implementation of the passive STS would return. If we instead decide to go for interoperability (which is what is described in the document with the different banks offering the brokerage services) then the active STS would need a compound key to identify the user. One part of the key would be a value that identifies the issuing STS (much like a bank routing number) and a value that is generated by that STS (much like a bank account number) where the combination of the two pieces of information would uniquely identify a user. The advantage of the interchangable approach is that it will be easier to set up and maintain the database. The advantage of the interoperable approach is that several passive STS users could map to a single active STS user. The disadvantage is the additional (not large) database records that would be needed to add new passive STS instances. The decision above will have an impact on the claims that are produced by the passive STS. If we were starting this effort from scratch the claims would probably contain most/all of the information needed for personalization of the UI. The current application does not have personalization based on the user and I don't want to add a lot of extra work just for this but I think we could add the following claims to the passive (web) token. - Name - Issuing STS Identifier (if we use interchangeable STSs) - Unique identifier (this would identify the user on the front end web application) For the active STS I think we need at a minimum the following claims - UserName (i.e. uid:0) - profileID I welcome any discussion, comments, or suggestions on the proper way to handle the interoperability/interchangability and the claims contained in the tokens. Scott Golightly
