Saturday, November 30, 2013

How I learned claims based authentication

30/No/2013

Starting Skillset: .Net 4.0, Azure certified, has high level understanding of claims

Going through an excellent article
http://www.codeproject.com/Articles/504399/Understanding-Windows-Identity-Foundation-WIF-4-5

Description about all the parties (IP,RP, etc) was interesting
AHAs:
1) STS is a service residing in IP(Identity provider)
2) WS-Trust is a specification which has a rule:-
        a) A message request called RequestSecurityToken (RST) needs to be issued to the  STS.           
        b) STS in turn replies via a response called RequestSecurityTokenResponse (RSTR) that holds   the security token to be used to grant access.
3) WS-Federation uses WS-Trust.
4) Web services are called active clients Browsers are called passive clients(because of iFrame redirection? )Ans: Browsers are passive because they just perform redirects they are told to, but by themselves browsers have no notion of WS-Federation
5) WS-Federation does not mandate a specific token format
6) IP puts claims for rp as agreed with rp beforehand.
7) Authentication is a separate module can happen somewhere outside app too but authorization happens in our code.
8) Claims undergo transformation/validation once received(later realized [13/12/13] that this can happen on ADFS as well] why the different ways?
9) Need to decouple business logic from authorization logic.([13/12/13] Why is this important in Claims based architecture perspective and not from traditional approach?)
10) WIF is Microsoft’s technology for encapsulating the inner workings of WS-Federation (and WS-Trust) behind a .NET library
11) HTTP modules does the job (WSFederationAuthenticationModule/SessionAuthenticationModule)

Date: 1/Dec/2013 (contuinuing same url)
12) Browser post back is confusing. How does that happen? Why should the request travel all the way back to client browser. Why can't RP redirect directly to IP before authentication and vice versa after authentication?
(Got a clue from a collegue on 11/12/13,
1) RP and IP cannot keep a line of connection (against: what if RP calls STS web service and gets the data in response) 
2) to manage cookies/session(against: but can't RP finally return the cookie?),
3) it is the browsers responsibility to pass the credentials to IP(good one)
not convinced fully so asked a question: http://stackoverflow.com/questions/20567828/why-rp-and-ip-communicates-through-browser-instead-of-going-directly)
13) IP gives public certificate along with the request.
14) The RP uses its private key to decrypt the contents.
15) R-STS was interesting. Especially when ACS was mentioned.


Did not understand:
WIF for Active Clients section: diff between active and passive.


Finished the url and now moving on to Another related article by genius mohamad halabi 
Inreoducing ADFS: http://thedotnethub.blogspot.nl/2012/12/adfs-20-by-example-part1-adfs-as-ip-sts.html

Time: 13:00 (same date 1/Dec/2013 )

AHAs
1) In VS2102 adding an STS through 'Identity and Access' turns the application to RP (proof in  web.config) and also the required HttpModules + federatiometadata.xml.
2) federationmetadata.xml is referenced in ADFS module to add RP as trust party there.
3) Single signon : Sessionmodule does the job. Nothing to do more. Cookie helps in SSO.
4) account stores vs attribute stores. account stores has to be AD. attribute store can be in different(sql server for eg:)

2/12/2013 : 20:29
Slightly deviating from claims based authentication & WIF today. For work I need to figure out OAuth to be used to with AD. So that in the next quarter we could go to cloud(Azure AD) with minimal change.
And I found, guess who? inspirational Vittorio Bertocci himself!!
http://channel9.msdn.com/Events/TechEd/NorthAmerica/2013/WAD-B307#fbid=

AHAs
1) OAuth was used in Azure before AD(on-premise)
2) OAuth can easily be used in AD with out much change to the code. Infact you can have more features available. (exactly what I wanted for work.


Date: 13/12/2013
Vittorio reading stopped briefly as this was taken out of scope by project. But the scope changed again and I have been looking into something else instead

These questions sums it up what I was into these days:
1) http://stackoverflow.com/questions/20530119/local-sts-to-production/20530352#20530352
2) http://stackoverflow.com/questions/20550426/wif-with-out-using-sts/20552887#20552887

Ans: I would need a custom STS to go with claims based authentication. Which is an extra effort. So I might go with windows authentication and switch to ADFS when it is ready.

Sql Server role provider could be used with ADFS is another good thing I learned: from here http://www.syfuhs.net/post/2010/09/14/Claims-Transformation-and-Custom-Attribute-Stores-in-Active-Directory-Federation-Services-2.aspx#comment

But here is the question:
  1. If ADFS is configured to use our sql server, what would other applications do? ADFS will be shared by a number of apps I guess.
Ans: May be the role management should still be done by my own app using sql server. and is stored in a session cookie. I am gonna ask a question on Stack Overflow! right away! There we go http://stackoverflow.com/questions/20567250/adfs-roles-from-sql-server
 
Okay see you next time !

13/12/2013 23:56
based on some of the responses I got on the question mentioned earlier (http://stackoverflow.com/questions/20567828/why-rp-and-ip-communicates-through-browser-instead-of-going-directly) focus is now on passive vs active federation. Which again brought me to the master : http://www.cloudidentity.com/blog/2008/06/05/ACTIVE-PASSIVE-AND-PASSIVE-AGGRESSIVE/ 

in here Don says "WS-Federation extends WS-Trust to provide a flexible federated identity architecture with clean separation between trust mechanisms, security token formats, and the protocol for obtaining tokens"

This is interesting and actually I had guessed it: WS-Trust and other specs are building block which provide protocol “primitives”. WS-Federation gives a script in which some of those primitives are composed in certain sequences for obtaining higher level outcomes such as sign-in, sign-out, the works.

clients(requesters) were classified according to their ability of producing SOAP messages:


I am getting more to write from the document
The lack of SOAP capabilities forced some creative solution for “emulating” WS-Trust on top of GET, POST and cookies: the result is the above mentioned dance of redirects, where the browser goes back & forth between previously established addresses on the resource and requestor domains and using cookies for communicating authentication information. THIS is what is meant by passive federation.