6 comments

• 

  karl_mcguinness

  9 months ago

  Good to see other folks doing the same thing. We just finished prototyping a similar approach. Instead of using custom headers, have you thought about using WS-Security Token Profiles over HTTP headers so that you can leverage the existing profiles and library support? (see http://www.xml.com/pub/a/2003/12/17/dive.html) . WS-Security has a standard profile for SAML tokens so you can also use this approach to normalize your SOAP and REST strategies in WCF.
  reply
• 

  nstults

  9 months ago

  That looks to be a much better approach, thank you for posting the suggestion and link. How is your prototype going? Does it work?
  reply
• 

  JoeG

  8 months ago

  I'm a bit confused (nothing new for me ;). I thought that in the "Identity Triad", the subject (in this case, your Windows Forms client) wasn't supposed to have access to the claims contained in the token. The IP creates the claims, then hands them to the subject in the form of an encrypted secure token. They are then passed to the RP in the encrypted form. I don't believe that Zermatt will facilitate handling of the claims by the subject via IClaimsIdentity, only by the RP.
  reply
• 

  nstults

  8 months ago

  In my example there isn't actually an Identity Provider involved - the service consumer (the Windows Forms client) is acting as the IP, which is where your confusion comes from. In a real scenario the service consumer would likely facilitate the retrieval of an encrypted token for the logged in user from a real IP and then use the technique I described to flow that token to the service. In my simplified example, however, the service consumer is constructing a dummy token because this sample isn't concerned with that part of the Identity relationship. And I don't think you would call any piece of software the "Subject" - the Subject, in my limited understanding, is the conceptual entity being authenticated, i.e. a user. Usually the RP and the application the user is logging into are the same, so the application itself is the Relying Party (RP). In my sample, logically, the windows forms application is just the user interface to a distributed application, and the whole thing could be considered the Relying Party. The role of the Identity Provider is somewhat obscured by the fact that the UI (service consumer) is pretending to be the IP.
  reply
• 

  JoeG

  8 months ago

  Thanks for the clarification of the "Subject" concept; a lot of this stuff is still gelling in my brain. I guess where I'm still a little fuzzy on what you're trying to achieve comes from the phrase, "On the client side...a representation of the user along with her claims can be found at Thread.CurrentPrincipal." I'm not so sure this is the case with the Identity Metasystem model I have been reading about as of late. As I understand Zermatt, IClaimsPrincipal and IClaimsIdentity are concepts that don't apply to the client-side of things (thinking of the client as a web browser in the ASP.NET world, and a Windows Form in the rich client world).
  reply
• 

  nstults

  8 months ago

  I think you may be reading into the Identity Metasystem too specifically - in my understanding, client or server is not the question, simply the relative, identity related roles of whoever is participating in an identity transaction. I see no reason a smart client (such as a Win Forms app) couldn't play the role of a Relying Party. You can't really compare a web browser front end to a smart client front end as if they were counterparts - a smart client may, for instance, require the users claims to appropriately render its UI (i.e. hide or show certain features based on access rules), whereas a web app will rely on the "server" to fill this role as the server generates the user interface. I can't imagine client side code in a browser being able to examine claims, or wanting to, but it is not at all unreasonable for a smart client to do so. In other scenarios a web app may actually be acting as a "client", delegating to a distributed service layer for its business logic and concerning itself only with rendering a UI, and in that scenario the web app may also want access to a users claims. If the front and and back end are just tiers of a single application, I don't think this is a problem. I could be misunderstanding some very important point here, though, that has been known to happen.
  reply