title: .net n-tier identity & authorization in service architecture
body: <p>I'm building an application where the requirements seem standard issue (at least to me)... I have a Web.UI based on asp .net mvc &amp; clients from iphone, andriod &amp; blackberry.</p>
  
  <p>So the sensible thing to do is to move all my business logic into a services layer that can be accesses over http. This services layer must accept requests with a user context (identity) and in some nice way perform authorization consistently no matter which type of client is communicating with it (I hope?).</p>
  
  <p>Over a year a go I did a 3 month gig that employed W.I.F. (Windows Identity Foundation) in a hybrid on-premises &amp; cloud architecture. I liked it. The 3 things that struck a chord were (1) externalizing authentication and not caring how it was done, (2) removing authorization logic from business logic, (3) Claims based authorization.</p>
  
  <p>Over the last year I've heard and watch all about Rest Services the 'new cool hippy way of doing things'. So I though great, let's try that. After I started to play around &amp; get coding, I started getting really confused (and subsequently read for about 10 hours yesterday without writing another line of c#). I'm still confused about all the SOAP vs REST, WS.* vs Http, SAML vs SWT babble. I don't really want this thread to be about that because there is enough of that speak on stackoverflow, but I feel like I've got a choice between two camps, when it doesn't really feel like I want one or the other but bits from each?</p>
  
  <p>To me the 3 points I mentioned above about WIF don't seem like concepts that should be tied to WS.* ? But I'm getting the feeling that they, or at least how WIF comes at the moment makes them, without some expert tweaking (e.g. I came across this post only written a few days ago - <a href="http://zamd.net/2011/02/08/using-simple-web-token-swt-with-wif/" rel="noreferrer">http://zamd.net/2011/02/08/using-simple-web-token-swt-with-wif/</a>).</p>
  
  <p>The other areas I don't know much about is are my clients (iphone, andriod, blackberry) capable of playing with WIF, is it the same STS that throws a SAML token to them and they behave just like a browser and pass it back in a header just like any other client? Yes I'm going to have to find out, but if this is a deal breaker with W.I.F and I find out straight after posting this, then at least I can focus away from it.</p>
  
  <p>Finally to throw one more thing in the mix. I don't really want to think about any of this. I want to use a 3rd party authentication / identity provider - <a href="http://www.janrain.com/products/engage" rel="noreferrer">http://www.janrain.com/products/engage</a> - which I believe uses OpenID. Can this fit into W.I.F. or do I just create a new SAML token from the OpenID and use WIF from that moment on.</p>
  
  <p>I guess at the end of this babble, I want to come back to where I started because it's getting more and more complicated the more questions I ask and the more options I consider.</p>
  
  <p>Is having a services layer (on WCF) that talks to different non-.net clients that requires identity context and authorization so strange? If you've build something like this, how did you approach it?</p>