Hello!
The comments on this profile are unclaimed and thus are unverified.
Do they belong to you? Claim these comments.
JoeG
Is this you? Claim Profile »
8 months ago
in Flowing Identity from a Client to a Service when using RESTful WCF Part 2 - A Solution on The Freak Parade
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).
1 reply
nstults
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.
8 months ago
in Flowing Identity from a Client to a Service when using RESTful WCF Part 2 - A Solution on The Freak Parade
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.
1 reply
nstults
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.
