Kent,
You are correct that WS-Trust and ActAs are the main updates. A concrete example of the difference between interchangeable and interoperable STSs might help clarify what I mean. For the interchangeable scenario we would agree to something like the following mapping Passive STS claim value Current Stonehenge ID 12345 uid:0 23456 uid:1 34567 uid:2 All of the passive STSs would use the same value for the Passive STS claim value and it would map to a user id. This would require a simple lookup table at the active STS. For the interoperable scenario the following passive STS values could all map to uid:0 Passive STS Passive STS claim value DotNet 12345 WSAS 12345 Metro ABCDEF The mapping for uid:1 could be DotNet ABCDEF WSAS 1842 Metro 27324 The main difference is that in the interchangeable scenario every passive STS would produce the same value for a given user and the lookup table would be easy to construct and low maintenance. In the interoperable scenario each passive STS would generate a value for the claim. The combination of the passive STS name and value would make the lookup unique so there would not have to be any coordination of the values for the STS. The setup would be a little more complicated due to having more entries in the lookup table but once the script was created to populate the lookup table it shouldn't take any more maintenance than the interchangeable scenario. I think either solution would fit a "real world" scenario. If we were to take the analogy in the document of a brokerage and different banks I could argue that in the interchangeable scenario the value would be my social security number, passport number, or some other identifier issued by a government or other authority that would uniquely identify me and I could use that same identifier at several banks. For the interoperable scenario I could equally argue of a situation where I might have accounts at 2 banks with different bank account numbers at each bank but I want to have both bank accounts map back to the same brokerage account to make it easier for me to manage my stock holdings. In this case I think the choice comes down to what we as a group want to do in the way of setup and then later on adding new accounts. Scott Golightly > From: [email protected] > To: [email protected] > Subject: RE: Claims based authentication > Date: Thu, 2 Jul 2009 20:30:05 +0000 > > 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
