Window Identity foundation is basically a platform and add on Microsoft technology which provided the solution to outcomes with the secure authentication and authorization and to maintain the identity of the objects.
As we know the technology is randomly changing according to the demand and the upcoming scenarios and the requirement of security and other aspects.
What happens if someone comes and say all your side need to be follow this security norms, you will lose you data if not applied?
What happens if sometimes later all your side need to redefined the new pattern of login?
What happens if your site existing use want to access your side from other portal without providing the login credential but ensure that would be secure
What happens if your site multiple user, Let’s say A use ask to provide login from website(Domain) 001 through X technology., user B ask to provide login from Website(Domain)002 through y technology and so on.
So basically we can provide this solution but to maintain the identity of the user with cross domain and to support multiple channels (like oAuth, Saml, Windows/AD/Kerberos etc._
We required a centralized mechanism to maintain all this channel and support all these channel.
Here is the solution from Microsoft --- Window Identity Foundation----
We will try to cover some basic about Window Identity Foundation and how it will be work in the live scenario.
Windows Identity Foundation (WIF) is a Microsoft software framework for building identity-aware applications. It provides APIs for building ASP.NET or WCF based security token services as well as tools for building claims-aware and federation capable applications.
Windows Identity Foundation (WIF) is a framework for building identity-aware applications. The framework abstracts the WS-Trust and WS-Federation protocols and presents developers with APIs for building security token services and claims-aware applications. Applications can use WIF to process tokens issued from security token services and make identity-based decisions at the web application or web service.
· Build claims-aware applications (Relying Party Applications). WIF helps developers build claims-aware applications. In addition to providing a new claims model, it provides application developers with a rich set of APIs to help making user access decisions based on claims. WIF also provides developers with a consistent programming experience whether they choose to build their applications in ASP.NET or in WCF environments. For more information, see Claims Consumer - Relying Party Applications.
· Easy trust establishment between claims-aware application and STS. WIF provides a utility, named FedUtil, to allow easy trust establishment between claims-aware applications and an STS, such as Active Directory Federation Services 2.0 and a LiveID STS. FedUtil supports both ASP.NET and WCF applications. It is also integrated with Visual Studio so that it can be invoked from the Solution Explorer by right clicking on a project and choosing "Add STS Reference" menu item, or from the Tools menu in Visual Studio. For more information, see FedUtil - Federation Utility for Establishing Trust from an RP to an STS.
- ASP.NET Controls. ASP.NET controls simplify development of ASP.NET pages for building claims-aware Web applications. For more information, see Establishing Trust from an ASP.NET Relying Party Application to an STS using the FederatedPassiveSignIn Control.
- Translate between claims and NT tokens. WIF includes a Windows service named Claims to Windows Token Service (c2WTS) that acts as a bridge between claims-aware applications and NT token based applications. It provides developers with an easy way to convert claims to NT-Token identity and makes it possible to access the resources that require NT-Token based identity from a claims-aware application. For more information, see Claims to Windows Token Service (c2WTS) Overview.
- Build identity delegation support into claims-aware applications. WIF offers the capability of maintaining the identities of original requestors across the multiple service boundaries. This capability can be achieved by either using the "ActAs" or the "OnBehalfOf" functionality in the framework and it offers developers the ability to add identity delegation support into their claims-aware applications. For more information, see Integration with IIdentity and IPrincipal and Identity Delegation Scenario.
custom security token services (STS). WIF makes it substantially easier to
build a custom security token service (STS) that supports the WS-Trust
protocol. Such an STS is also referred to as an Active STS.
In addition, the framework also provides support for building an STS that supports WS-Federation to enable Web browser clients. Such an STS is also referred to as a Passive STS.
The framework offers built-in Visual Studio Templates for building ASP.NET STSes and WCF STSes; these templates create simple STSes and developers can extend these and implement production STSes that suit their needs. For more information, see How to: Build an ASP.NET STS and How to: Build a WCF STS.
WIF supports the following major scenarios:
- Federation. WIF makes it possible to build federation between two or more partners. Its support for building claims-aware applications (RP) and custom security token services (STS) helps developers achieve this scenario. For more information, see Federation Scenario.
- Identity Delegation. WIF makes it easy to maintain the identities across the service boundaries so that developers can achieve an identity delegation scenario. For more information, see Identity Delegation Scenario.
- Step-up Authentication. Authentication requirements for different resources within an application may vary. WIF provides developers the ability to build applications that can require incremental authentication requirements (for example: initial login with Username/Password authentication and then step-up to Smart Card authentication). For more information, see Step-Up Authentication Scenario.
What is problem actually:-
Authentication (and authorization) is an ever present challenge for most applications. The challenge that these applications face is the same: authentication logic creeps into the application code and becomes coupled with it; any change to the authentication requirements will result in a change in the application itself.
Say for example that your user store is SQL Server and new business mandates adding an existing Oracle-based user store to your list of users, or maybe you want to mix your authentication to support both custom user stores (SQL Server or Oracle) with Active Directory user store. And what about social media? It’s increasingly popular nowadays for applications to allow authentication via services such as Google and Facebook.
Here is another tough case: assume you used to ask you users for username/password combination to log in. Now based on certain needs, you want them also to supply additional information such as a one-time code. This will certainly lead to UI change for your login page as well as code change.
In all these cases, something has to change in your code. Of course, having a good architecture with a proper separation of concerns will ease up the change. However, the idea is that you still have to manage this authentication logic instead of focusing on the business side of your application.
Claims-based authentication is the architecture that solves this problem.
Claims-Based architecture allows you to delegate authentication logic into another entity. This entity is a “some” layer which abstracts all authentication related coding and gives your application what it needs: is the user authenticated or not, and some information about the user (called claims or assertions) that lets your application take authorization decisions.
The claims-based architecture defines the following actors:
· Subject: the entity that needs to be authentication. This can be a user that wants to log in to your application, or a piece of code in your application that wants to access a web service.
· Relying Party (RP): the application (in case the Subject is a user) or the web service (in case the Subject is application code) that needs to delegate the authentication logic
· Identity Provider (IP): the entity (that “some” layer mentioned before) that actually holds the authentication logic. The IP talks to the user stores as appropriate and performs actual authentication.
· Claim: When an IP performs successful authentication, it returns to the RP a set of claims. Claims are statements about the authenticated entity – for example birth date, department, role, etc… – that gives the RP information to take authorization decisions.
· Token: Claims travel inside a token. Although a token can be a username/password combination or even a simple string such as bearer token in OAuth 2.0; in this context tokens can be either XML-based such as SAML tokens or binary-based such as X.509 certificates.
Before starting the SSO both the parties need to share their policies through the metadata.
WS-Security is a SOAP extension that adds authentication/authorization, message protection, and message integrity to SOAP messages.
· Authentication/authorization: authentication is implemented using security tokens while claims carried inside a security token aid in authorization. Although can be extended, the three types of tokens you’d usually see are Username, Binary, and XML-based tokens.
· Username tokens: these are the plain-old username/password combinations sent in the SOAP header. Verification of identity can be achieved by hashing the password or applying a digital signature.
· Binary tokens: these usually come in two flavors: X.509 certificates and Kerberos tickets.
o X.509 certificates: an X.509 certificate is the public key container of a public/private key pair. Obviously since it contains a public key it cannot be relied upon for authentication by itself. The certificate is signed with the private key portion of the sender. The receiver uses the public key to verify the signature. Since the private key is unique for the sender, signature verification proves identity
o Kerberos tickets: if a Kerberos infrastructure is already in place, WS-Security recognizes Kerberos tickets as a valid security token type
o XML-based tokens: XML tokens were published as an ad-on specification to WS-Security. XML tokens contain a set of claims about the sender. Similar to X.509 certificate tokens, XML tokens must be accompanied by a signature generated by the sender so that the receiver can verify its identity. Probably the most dominant form of XML tokens is SAML token.
· Message protection: Whereas at transport level message protection is established using SSL, at message level this is done via XML Signatures. Depending on the configuration, WS-Security uses either a symmetric shared key or an asymmetric public/private key pair to encrypt the required message content. In the symmetric approach the shared key must be exchanged securely prior to communication. In the asymmetric approach the sender encrypts the (required) message content using the receiver’s public key and the receiver decrypts it using its private key. Most of the time though, the approach used is a combination of both due to the fact of asymmetric approach being compute-expensive. In this hybrid approach, asymmetric encryption is used to exchange a shared key and then this shared key is used for encryption for the rest of the session communication.
· Message Integrity: as discussed in the authentication section, XML signatures are used to establish user identity. It is also used to establish message integrity; i.e. that the message has not been tampered with. By attaching a signature with a message, the receiver recalculates the signature and verifies integrity if both signatures match. Similar to encryption, a hybrid approach is usually used to reduce the cost of asymmetric-based signatures.
WSDL does a good job describing basic web service requirements such as message schemas and authentication headers. However, WSDL cannot describe contractual requirements such as security. For example, recall form the previous section of Claims-based architecture, that an RP-IP interaction is governed by a set of security policies. These policies cannot be described using WSDL; instead they are described by WS-Policy and its related specification WS-SecurityPolicy.
In general, there are WS-Policy assertions for security, reliable messaging, sessions, transactions, reliable messaging, among others. In WCF, these policies are specified either as code attributes or configuration sections.
o WS-Policy: a specification that defines a framework for describing policy assertions. An assertion is a requirement or preference of the service. This specification defines a common language regardless of the assertion domain (security, transactions, reliable messaging, etc…).
o WS-PolicyAssertion: a specification that defines general messaging-related assertions for use with WS-Policy. Separate assertions exist for different domains; for example, WS-SecurityPolicy, WS-AtomicTransactions, and WS-ReliableMessaging.
o WS-PolicyAttachment: a specification that describes how policies are attached to WSDL (and UDDI).
STS commercial products are available and you are likely to use them. Some of these products are:
o Active Directory Federation Services (ADFS) v2
o IBM Tivoli Federation Manager
- Oracle Identity Manager
- Forms Authentication removed: your RP now is neither windows nor forms authentication-base. It is a claims-based application, so forms is disabled because forms is the default when creating a VS web forms app.
- Two HTTP modules that makes WIF magic possible:
- : this module intercepts incoming requests and redirect unauthenticated ones to the trusted IP(s). For authenticated requests it processes claims within the security token and presents them to your application in a consumable format.
- : this module takes care of session management after an authentication is established. The module is bypassed and handles requests until the session is expired or a sign-out flow is invoked.
- : lists the URIs that your RP will consider valid for the received tokens
- : the list of trusted IP certificates that the RP will accept signatures from to verify the token
- : configures the WS-Federation protocol, such as using the passive protocol flow, the IP that the protocol will talk to, and the realm which is basically the ultimate return-URL that the protocol flow will end up in – the RP itself in this case.
In addition, VS 2012 has created a FederationMetadata.xml file in the RP solution. Recall from the discussion of WS-Federation that organizations participating in federation should publish communication and security requirements in Federation Metadata. This XML file holds these requirements for this RP.
Now run the application, quickly notice the browser navigation and you will see that your application gets redirected to the local STS which performed the (hardcoded) authentication and returned back to your application as an authentication user (assume you’re Terry for a moment!). You can now access the claims inside your application just like we have seen before.
Now let’s see what happened in the background to examine WS-Federation and the supporting protocols discussed before in action. To do so, I will use Fiddler:
Step 1: A user browses the RP
You asked for the application via the browser. The WIF HTTP module WSFederationAuthenticationModule detects that you are not authenticated, so it redirects the browser back with a 302 response and with a Location header that contains the address of the IP-STS at which you must authenticate. In addition, a set of WS-Federation protocol query strings are also supplied to govern how the flow will behave:
· wa: with a value of wsignin1.0 which means that this is a sign in request (note that WS-Federation also supports sign out flow, so this parameter is mandatory)
· wtrealm: this is the RP itself, and it represents the intended consumer of the token
· wct: this is an optional parameter that specified the time of the response of the RP. This might be used as indication to possible attacks if the IP sees that there is a time lag between this parameter value and the actual time it received the sign in request
Step 2: The browser sends a GET request to the STS
The browser then uses the STS address in the Location header and the query strings discussed before to assemble a sign in request to the STS. Here is the request made to the local STS:
Step 3: The IP-STS performs authentication
In “real” scenario, the STS will normally present you with an authentication form that you would supply your credentials to. This procedure of STS authenticating users – as mentioned before – is outside the scope of WS-Federation and thus WIF. The STS can authenticate you against an AD, a custom user store, or even using an X.509 certificate. This depends on the type of the RP application and where the users are coming from. Regardless of the mechanism to authenticate, the STS will – assuming successful authentication – generate a security token containing the claims agreed between the IP and RP via policy.
Step 4: The STS sends the response back to the browser
The STS sends back to the browser a hidden form with will POST back to the RP. The form contains the following information:
· wa: same as before indicating a sign-in flow
· wresult: contains the SAML security token issued by the STS.
If you carefully examine the response, you will see many of the protocols discussed before coming into play:
· The RequestSecurityTokenResponse (RSTR) of WS-Trust carries the token collection
· XML Signature of WS-Security is used to provide message integrity and trust between the IP and RP
· WS-Policy – driven by the Federation Metadata – indicates rules such as token lifetime
· WS-Addressing is used to identify the endpoint reference for the passive request (i.e. the RP)
I reformatted the content for ease of display, here you can see these protocols in action:
Note: There is a difference between SAML-P (the protocol) and SAML token. SAML-P is a full blown protocol much like WS-Federation. SAML token is a token type that can be used independent of SAML-P, and it’s one of the token types frequently used in WS-Federation.
I will briefly touch on SAML-P 2.0 at the end of this article.
Step 5: The browser posts back to the RP
The browser uses the hidden post form from the previous step to post the result shown in the previous step back to the RP
Step 6: The RP verifies the token
Verifying a token involves multiple checks that could take place based on each situation and policy. Some of these checks are:
· Integrity: in case digital signature is used, the RP uses the IP public certificate included in the request to verify that the digital signature is valid
· Expiration: in case an expiration for the token is present, the RP verifies that the token is not expired
· Decryption: in case encryption is used, the RP uses its private key to decrypt the contents. In the above example, encryption was not used as we were in the passive (web browser) case, later I will discuss the active case and illustrate the difference.
· Source: using the policy, the RP makes sure the token is issued by a trusted IP
· Claims: also using the policy, the RP checks that the set of claims issued are the ones agreed on
Step 7: A session cookie is issued
Once the token is verified, the RP issues a session cookie back to the browser so that next requests do not pass through the same WS-Federation process.
WIF for Active Clients
The browser-based scenario we have just seen is called a passive scenario. Passive clients are those that do not possess the WS-* capabilities. Browsers are passive because they just perform redirects they are told to, but by themselves browsers have no notion of WS-Federation.
Another type of clients are active ones. Active clients are those that can perform WS-* operations; an obvious example are WCF services. A WCF service can also act as a claims-based enabled RP. In this scenario, the client (the Subject as per the defined terminology) is an application calling the WCF service which requires claims-based authentication from a trusted STS.
The full cycle goes as follows:
· An application reaches a line where it is invoking a WCF service. The WCF service itself is an RP configured for claims-based authentication.
· The WCF client library at the application finds out that the WCF service needs a security token to grant access. The library then issues an RST to the STS.
· The STS replies back with a security token via RSTR
· The client application then uses this token to access the WCF service. Now here you can spot a major difference between the passive and active scenarios. Recall in the passive case that the client (browser) had only Https as option for encrypting its request to the RP – called transport level. In the active case, the client (application) can actually use the token to perform custom message level encryption on the message. Message level security has the benefits of better performance as we can be selective for which parts of the message are deemed sensitive and thus to be encrypted and it also supports end-to-end messaging.
The good news is that when it comes to WIF, you do not have to learn anything new than what you saw in the passive case. The same programming model applies. Again you can right click a WCF project in VS 2012 and configure it as an RP using the “Identity and Access” wizard. The defining difference between active and passive clients becomes clear when you inspect the web.config of the WCF service; you will see the ws2007FederationHttpBinding in use, which again shows you that active clients are WS-* aware.
So far the discussion has been centered on one role that STS can play, and that is issuing claims on behalf of an IP; and thus it has been called an IP-STS. However, an STS can play another roles; the role of a Federation Provider.
Let’s recall the scenario I discussed before of the two companies A and B wishing to enter a federated business agreement. In that scenario I gave an example of B users needing to access a (single) application in A and how that application is configured as an RP for an STS in B.
Now let’s extend the scenario a bit: instead of B users wanting to access a single application in A, both companies want to extend their partnership and now B users must be able to access multiple A applications. Under the role of IP-STS we have discussed so far, every A application must establish trust with B IP which in turn must provision every A application.
A far better solution is for A to expose a Federation Provider. A Federation Provider is a Resource STS (R-STS) that sits on the resource side (on the relying party side – A domain in this case). Company A applications then establish trust with the R-STS and B then provisions this STS only.
A typical flow will then goes as follows:
· An employee on B domain tries to access an A application
· A detects (via WIF for example) that the user is not authenticated and redirects the request to the STS it trusts; in this case it’s the R-STS on A’s domain
· In its turn, the R-STS is configured to accept tokens from B IP, so the request is redirected back to B IP
· The user authenticated herself again B IP using any mechanism defined by B
· A request is submitted to the R-STS on A containing the token
· R-STS processes the request and typically does one of 3 things:
o Issue claims exactly as they were sent from B IP. Here the R-STS decides that the included claims satisfy A application needs
o Modify claims based on some rules, for example to satisfy special formatting needs for A applications
o Add new claims that the R-STS knows are important for A applications yet B IP had no information about. For example R-STS might maintain some information from previous transactions for a specific user.
· The resulted token is then sent to the originally request A application which grants access
Once again, using WIF you can create your own local R-STS; although as explained before, in real scenarios you would go with commercial products. ADFS v2 is also suited to play the role of R-STS; for example its claims-transformation language is ideal for claims modification. Another great example is Azure Access Control Service (ACS) which also plays the role of a Federation Provider on the cloud.
I will close this article by briefly addressing SAML 2.0. Please note that I have never implemented this protocol myself, rather what I present here is a summary answer for the common question of WS-Federation vs. SAML just to get you going; but you’ll have a lot of reading to do if you want a definitive answer.
SAML 2.0 consists of two parts; a protocol (much like WS-Federation) that defines interactions and supported communication protocols, and a token format – conveniently called SAML token. The token specification is separate from that of the protocol, so you can use the token in another protocols. Actually that is what we have been doing in this article all along by using SAML tokens to carry claims in the WS-Federation protocol.
From a very high level point of view, SAML 2.0 protocol (SAML-P) achieves the same objectives of WS-Federation: it allows business partners to enter a federation agreement and allows delegation of authentication logic from an application (Service Provider) to an external entity (Identity Provider). The Identity Provider creates a SAML assertion that the Service Provider then validates to grant authentication. The SAML assertion is a SAML token containing claims.
SAML specification is actually divided into multiple parts:
· SAML core: this specification defines the structure of the SAML assertions and the supported protocols. You can think of this as the base of every other specification
· SAML bindings: each of the protocols described in the core specification is detailed in the binding specification where each binding has certain communication and formatting requirements
· SAML profiles: the profiles specification puts together the different specification into a usage profile, such as the login and logout profile.
· SAML metadata: this specification is basically what makes SAML-P tick. It defines the agreement requirements between the Service Provider and the Identity Provider to establish SAML-P (supported bindings, certificates, cryptography, etc…). Basically this is to SAML-P what WS-Trust is to WS-Federation.
WIF does not support SAML-P, although some time ago an extension to WIF that adds SAML 2.0 support was CTP’ed but has not took off since then. Here you can see the announcement:
It’s not all bad however, ADFS 2.0 however fully supports SAML 2.0 protocol. Why is this great news? Well simply because of the range of interoperability scenarios that is now possible between two environments one adopting WS-Federation and the other SAML-P. So organizations that have already a SAML-P-based protocol infrastructure in place, does not need to change in order to be interoperable with an ADFS-based one.
6. Open Question
This looks good but have some open question and pending section.
1) Need a demo specific to WIF, how it will work for multiple channels like saml and Oatuth.
2) Integration with live IDP.
Date of Release
Summary of Changes