What is Relying Party (RP)

Wednesday, September 22, 2010

An application that accepts tokens from an STS is called as a Relying Party (or RP). In modern scenarios, web applications use WIF and accept tokens from an STS to manage authentications process.

These tokens acts a proof that user has been authenticated by our application. Thus, our application relies on an external service i.e. an STS to provide Access Control and thus our application is termed as a Relying Party.

More Explanation about Security Token Service.

What are Claims

The security tokens generated by STS contain various attributes based on which a grant/deny access is provided or based on which user experience is customized. These attributes are called as Claims.

A claim can be a user name, user’s email, it can even be permissions such as canWrite, canRead etc or it can be roles or groups to which the user belongs. When an STS generates a token, it embeds the claims within it; therefore, once a token has been issued the values of these claims cannot be tampered with.

If our application trusts the STS that issued this token, it uses the claims issues by the token to describe the user, thus eliminating the need to look up user attributes to provide authorization and customization.

What is Security Token Service (STS)

Traditionally, access control was implemented within the main application by writing a code against user’s credentials to authenticate them and based on their attributes grant/deny access to various resources. This required application developers to be skilled in implementing security and writing a code which is hard to implement and maintain.

Due to Windows Identity Foundation (WIF) all this has changed and it made the things much easier. WIF externalizes authentication and thus application designers can focus only on implementing Business Logic. So, instead of implementing authentication in our application, we use an external system to provide authentication. This system is nothing but a service, which generates secure tokens and transmits those using standard protocols such as SOAP. This service is known as Security Token Service or STS.

Our application is configured to accept these tokens generated by STS. These tokens act as the proof of authentication of a user and hence there is no need for our application to manage these credentials. In this case, our application acts as a Relying Party.

The tokens generated by STS also provide attributes of these users which can be used to prevent access to resources and customize user experience. These attributes are called as Claims.


Get this great book for more clarifications directly from master of WIF, Vittorio Bertocci

AppFabric ACS Exception: A potentially dangerous Request.Form value was detected from the client (wresult="<t:RequestSecurityTo...")

Monday, September 20, 2010

AppFabric ACS Exception : A potentially dangerous Request.Form value was

When you are working with AppFabric ACS labs and implement identity providers such as Windows Livefollowing error might show up when you try to run your application

A potentially dangerous Request.Form value was detected from the client (wresult="<t:RequestSecurityTo...").

This error occurs because ACS sends you a SAML in a POST request, as the wresult value token. ASP.NET considers this as if a user typed some XML content in a textbox called "wresult" which is considered to be unsafe by ASP.NET. ASP.NET considers this kind of values as potentially dangerous, as some kind of script injection.

Therefore, if in your application Request Validation is enables this exception is thrown.

As a solution, you need to add ValidateRequest="false" in your page or in you web.config. This is a required step in case you want to integrate AppFabric ACS.

AppFabric ACS September release is announced

Well, i was just over with integrating AppFabric ACS with windows azure cloud app, using the August release, and now i hear that September release is out.

September release of AppFabric ACS contains incremental updates including support for OAUth 2.0 Web Server, additional support fpr X.509 certificates, ability to upload WS-Fed metadat through portal, expanded support for machine keys.

You can read the announcement at Windows Azure blog. Documentation and updated samples are avaialble on CodePlex project: http://acs.codeplex.com.

Hosted first AppFabric ACS Labs integrated App on Azure

Wednesday, September 15, 2010

After all initial hiccups and with the help of MSDN forums and Justin Smith and Vittorio Bertocci's Blogs i have been able to integrate my web role with AppFabric ACS Labs.

What i implemented is just Single Sign On with Windows Live ID. Yes, only one Identity Provider, though i could have opted for Facebook Connect, Google and Yahoo too.

My next target is to implement ADFSv2 with Appfabric ACS and put it into cloud. Will update how i was able to do that soon.

What is Passive Federation

When i started working with ACS on Appfabric I kept on encountering various terminologies, one of them was Passive Federation and it was widely used. I could understand the term Federation but passive was not clear to me ever.

So, I did some research and finally got an answer by Vittorio at Vibro.net .

The term Passive refers to all those requests that are made by a requestor which is not capable of producing proper SOAP request, for example Web Clients. This means all Web clients are Passive Requestor. Passive Federation emulates WS-Trust on top of GET, POST and cookies. This involves multiple redirects involving browser, resources, requestor and cookies. Check the diagram by Vittorio for details.

At Present whenever someone refers to WS-Federation it simply means Passive Federation, as Active requestors are capable of handling WS-Trust directly.

So now if we are implementing Windows Live ID single sign on in a our application, may be by using Appfabric ACS Labs we essentially mean Passive Federation. I will be shortly talking about my experiences with AppFabric ACS Labs.

Followers

 

2009 ·Techy Freak by TNB