Accessing REST based service from Windows Phone 7.1 using SAML Token

Accessing REST based services from Windows Phone 7 client devices include two approaches: Active Federation implementation means how the client application uses OAuth protocol and contacts all the issuers in the trust chain in turn to acquire a valid SWT token to access a online enterprise application where as in passive federation mode device ‘s embedded browser requests the identity provider list from Access Control Service(ACS 2.0)  which in turn requests for token from trusted issuer & issuer sends back the SAML 2.0 token which is received by the device then it send a call to the enterprise REST service as Relying Party (RP) with Simple Web Token (SWT) Token.

• Comparison of the Federation Difference:
• The passive federation solution that leverages an embedded browser control offers a simpler approach to obtain an SWT token because the embedded web browser control in combination with the WS-Federation protocol handles most of the logic to visit the issuers and obtain the SWT token that the enterprise application needs.
• In the active federation solution, the Windows Phone Application must include code to control the interactions with the issuers explicitly. Also, the active solution must include code to handle the requests for SAML tokens from the Relying Party(Issuer).
• An advantage of passive federation approach is that it enables the Windows Phone Application to dynamically build the list of identity providers to your ACS configuration.
• You must explicitly add any SWT token caching behavior to the Windows Phone application for both the active or passive federation solutions.

• Download 9WindowsPhoneClientFederation from http://claimsid.codeplex.com to get Visual Studio development system  solution for Claims identity based REST services for Windows Phone .

Windows Azure Claims based Identity & Access Control ebook available

Most enterprise applications include a certain amount of logic that supports Identity -related features. Applications that can’t rely on Integrated Windows Authentication tend to have more of this than appeared to do. For example : web based applications that store usernames & passwords must handle password reset, lockout and other issues. Enterprise facing applications that use integrated Windows Authentication can rely on the domain controller.

• Claims based identity allows you to factor out the authentication logic from individual applications instead of application determining who the user is, it receives claims that identifies claims that identify the user.
• Microsoft annouced the second release of Claims Based Idenity & Access Control Book from Patterns & Practices Team.

Download from here: http://www.microsoft.com/download/en/details.aspx?id=28362

• For better explanation about SAML (Security Assertion Markup Language) Token 2.0, Simple Web Token (SWT) , Relying Party, Requesting Security Service (RST), Secure Token Service(STS) , ADFS (Active Directory Federation Server 2.0 Single Sign On ) issues with asp.net authentication & far more illustration about Windows Identity foundation 4.0 (WIF) , Identity Runtime, Web Resource Authorization Protocol 2.0 (WRAP) covered in this book.

• Concise explanation about Claims based identity in Windows Azure Web , Access Control Service(ACS), Service Bus Queues, Claims based identity with Sharepoint 2010 integration, Federated authentication with Sharepoint with Access Control Service(ACS V2)