StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>I'm going to take a crack at answering your question slightly more abstractly...</p> <p>Before I begin, my background is MS biased so there may be equal (or better) options available from other sources.</p> <p>Two references that I found very useful:</p> <p>1) A Guide to Claims-based Identity and Access Control</p> <p><a href="http://msdn.microsoft.com/en-us/library/ff423674.aspx" rel="nofollow">http://msdn.microsoft.com/en-us/library/ff423674.aspx</a></p> <p>2) Programming Windows Identity Foundation</p> <p>Author: Vittorio Bertocci Available in hard copy of kindle formats</p> <p>There are alot of other sources but these two cover several scenarios and give good background info for anyone that wants to get up to speed with your starting point.</p> <p>I encourage other posters to fill in any gaps or mistatements :) I'm glossing over a slew of technical details to focus on the question asked.</p> <p>The way I break federated identity down is, roughly, as follows:</p> <ol> <li>Application(s) [App(s)]</li> <li>Authentication service(s) [STS(s)]</li> <li>Claim Set(s) [Claim(s)]</li> <li>Trust relationship(s) [Trust(s)]</li> <li>Transport method(s) [Transport(s)]</li> </ol> <p>An STS is responsible for verifying the identity of a user and vouching for some claims. It does this by either providing (1) a signed blob containing the claims or (2) a unique identifier that a 3rd party can use to lookup the claims.</p> <p>An application that wants to provide a user with a service can "trust" an STS to provide it with claims it can use to work with the user appropriately, thus aleviating it of the responsibility of verifying the user (among other things such as maintaining centralized meta-data but I digress).</p> <p>There is also the ability for an STS to "trust" another STS, basically saying "If you say this person is Joe Smith and they have X, Y and Z roles, then I'll vouch for what you say!"</p> <p>So to paraphrase:</p> <p>App(s) "trust" an STS { which can in turn "trust" another STS } to provide it/them Claim(s)</p> <p>** Switching Gears **</p> <p>SOAP vs REST</p> <p>At the end of the day SOAP and REST are both Service types, lets call them Claims consumers. They both want someone to give them a bucket full of claims so they can do their work and send back some stuff. Additionally, both service types can be presented with claims via query string using a token (assuming the service can handle some url rewriting) or via a header (HTTP for REST and SOAP for, well, SOAP services). Either way the goal is the same: Transmit the claims or the UID to the App.</p> <p>WS* vs HTTP</p> <p>These (along with TCP/IP, SSL, secret decoder rings, etc) are methods of passing information back and forth, albeit with varying degrees of certainty that someone in the middle can't find a way to impersonate the user.</p> <p>SAML vs SWT</p> <p>These (along with base 64 encoding, xml, simple text, etc) are both methods of serializing claims. These two just happen to conform to standards that the others don't so everyone can speak the same language.</p> <p>** Getting back to the point **</p> <p>Each of those technology combinations are valid (depending on the application, some are less secure, others are easier to implement, others work better on lower level devices, etc) and are just one person's way of doing the job vs another's.</p> <p>So if I have a .Net application that has been served a set of claims in SAML fomat over a WS* pipeline the end result is that the applciation has [claims in SAML].</p> <p>With some processing these can be transformed into [claims in SWT].</p> <p>The new claims can then be packaged up and sent via HTTP/SSL to a Java application.</p> <p>IF the Java application "trusts" the same STS (or an STS that "trusts" the .Net apps STS) then it opens up the claims and does its work.</p> <ul> <li><p>The expert tweaking you mention has to happen, the question is simply by whom and how transparant is it</p> <ol> <li>Dave provides a perfectly valid example of one way to accomplish the tweaking with custom code.</li> <li>ADFS provides translation rules that try to accomplish merging and translation via configuration.</li> </ol></li> <li><p>The idea of having services on disparate platforms/devices/applications/etc is not strange at all, that's exactly the kind of scenario all this stuff is being built to address</p></li> </ul> <p>I am in the process of trying to build something like what you are asking about so I've been working on the same kind of issues myself.</p> <p>The Engage service you mentioned allows you to associate your application's users with outside sources and can be used to authenticate those users... ala "I see you authenticated with google as John@gmail.com, I know you as John Walker with an id of 4321, oh, look, you changed your favorite color setting in google to blue... carry on!"</p> <p>What it doesn't do is provide claims to your application that are specific to your application (unless all you need to know comes from the google data in which case you're likely building a mash up and not an LOB application...</p> <p>Another scenario:</p> <ol> <li>User goes to your application</li> <li>Is redirected to your STS</li> <li>Is redirected to Google</li> <li>Is returned to your STS</li> <li>Email and favorite color claims are added (per google)</li> <li>List of roles and purchase limit claims are added (from your application specific datastore)</li> <li>User is returned to the application</li> <li>User tries to buy $10,000 purple widgets and you say "Well, you can only buy $5,000 on credit and... are you sure you want purple I heard you prefer blue?"</li> </ol> <p>Another place that I would direct you to is the AppFabric Access Control service offered by Microsoft. (http://msdn.microsoft.com/en-us/library/ee732536.aspx) <em>disclaimer: I haven't used it yet</em> but, it looks like it does the kinds of translations you are looking for with a lot of the meat hidden away for you.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload