Neudesic Blogs

Passion for Innovation

Claims-based Federated Security Using Windows Azure Access Control Service and Third Party Identity Providers

When selling innovative products to third party customers, it is imperative that end users have the ability to use existing credentials to gain access to your product.  Users do not want to have to maintain more than one set of credentials to access their enterprise applications.  Products should federate with a user’s existing directory stores, authenticate and authorize seamlessly.  Imagine how frustrating it is for users to enter credentials each time they access a different application throughout their work day.

There are some important terms to know when creating a product that will federate with directory stores such as Active Directory and Open LDAP in order to save users the hassle of maintaining multiple credentials.

Important Terms

Federation: Federation refers to multiple security domains (or realms), usually of multiple organizations, and establishing trust for granting access to these multiple security domains through an authentication process that is trusted by multiple organizations. 

Subject: The entity that needs to be authenticated.  This can be a user that wants to log in to your application, or a piece of code that needs to access the external components like web services.

Claims: Claims are statements about the subject.  For example, the subject’s first name, last name, role, user ID, birth date, department, etc.  In fact, virtually any attribute pertaining to the subject can be a claim.

Relying Party (RP): The application or web service that needs to delegate subject authentication logic to external components.

Token: Claims travel inside a token and are usually part of a secured token issued by the Active Directory Federation Service (defined below) or the Security Token Service (also defined below).  Although a token can be a username/password combination, or even a simple string such as a bearer token in OAuth 2.0, in this context, tokens can also be either XML-based (like an SAML token) or binary-based (like an X.509 certificate).

Security Token Service (STS): Software-based service responsible for issuing security tokens.  STS should be highly available for all traffic from the Relaying Party and should also be scalable.

Active Directory Federation Services (AD FS): A software component developed by Microsoft that can be installed on Windows Server to provide single sign-on access to systems and applications.  AD FS can act as a Federated Service with the ability to federate multiple Identity Providers, and can also act as an on-premise STS.  AD FS comes bundled with Windows Server 2012.

Windows Azure Access Control Service (ACS): Cloud-based service that provides an easy way of authenticating and authorizing users to gain access to web applications and services, acting as an STS in the cloud.  ACS provides out of the box federation with popular social web identities like Google, Yahoo, Facebook, and Windows Live ID.  Developers do not need to write any code to integrate these web identities into their security solutions. ACS also acts as a Federation Service and has the ability to federate with WS-Federation based identity providers.

Third Party Identity Providers (IdPs): User directory services, or identity stores, that AD FS or ACS will look to when authenticating users, and upon successful authentication, will gather claims.  These claims will be part of a secured token and be passed on to the Relaying Party.  The Relaying Party can make authorization decisions based upon these claims.  Active Directory, OpenLDAP, Novell, SQL Server or any other relational database, as well as web identities like Google, Facebook, Yahoo!, and Windows Live Store, can all serve as IdPs.  These IdPs are usually located across boundaries from the Relaying Party.  The Relaying Party relies on these IdPs to authenticate users.  IdPs hold the Authentication logic.

WS-Trust 

So, now that you know the important terms, how do you get your application to federate a user’s existing directory stores, authenticate and authorize seamlessly?  This is accomplished by establishing trust between your application and the STS by delegating your authentication to a Third Party IdPs.

Assume two companies, A and B, want to conduct business.  Company A wants Company B’s users to access its application.  While there are more complex and difficult ways for Company A to authenticate Company B’s users, the easiest solution is for Company A to use Company B’s authentication instead of having its own separate authentication- in essence, having Company A trust Company B’s authentication of its users.

This is where WS-Trust can come into play.  WS-Trust introduces the concept of a Secure Token Service (STS), which is a web service that is responsible for generating claims that are trusted by consumers.  If Company A and Company B both establish a WS-Trust where Company A trusts an STS for Company B, Company B’s users can carry tokens issued by their STS and present those tokens to Company A, which trusts the STS and grants access to Company B’s users.

WS-Trust defines a message request called Request Security Token (RST) and issues it to the STS.  The STS, in turn, replies via a response called Request Security Token Response (RSTR) that holds the security token to be used to grant users access.  WS-Trust describes the protocol for requesting tokens via RST and issues tokens via RSTR.

WS-Federation

WS-Federation builds on WS-Trust and simplifies the creation of federated scenarios by defining a common infrastructure for achieving federated identity for both web services (called active clients) and web browsers (called passive clients).

WS-Federation dictates that organizations participating in federation should publish communication and security requirements in Federation Metadata.  This metadata adds federation-specific communication requirements on top of other security-related policies.  For example, token types and single sign out requirements are defined in the Federation Metadata.

WS-Federation does not mandate a specific token format, although SAML tokens are heavily used.

Claims-Based Architecture Diagram

The diagram below shows a typical example of how to create your claims-based architecture so that your application can authenticate using a Third Party Identity Provider.

 

 

In this architecture:

 

·         RP, STS, IdP, AD FS, Thinktecture, SQL Server, Security Tokens, claims, and https transport security are all involved.
·         Using WS-Trust Protocol, RP has trust with ACS/STS and ACS has in turn trust developed with all the involved identity providers.
·         WS-Federation protocol facilitates setting up the federation between RP, STS and WS-Federation IdPs. Each party exposes its Federation metadata XML file which helps consumers set up policies when interacting with that particular IdP like message security, token signing and encryption using certificates etc.
·         Other IdPs like Google, Facebook, and Yahoo are non WS-Federation parties. Google, Yahoo are based on OpenId 2.0 protocol, Facebook is based on OAuth protocol using Graph APIs. ACS works with these IdPs out of the box.
·         Above topology is a typical example of Passive federation – in which 302 browser redirects happen seamlessly.
·         This architecture is very scalable in nature. You can add more identity providers to ACS without affecting the RP at all.
·         User tries to request the RP web page.
·         STS Authentication kicks in at RP server and it sends back the browser URL to redirect to STS/ACS.
·         ACS receives the request and checks if any specific IdP are requested to be authenticated against. If any specific IdP is requested by RP, ACS redirects again to the IdP login URL.
·         If any specific IdP is NOT requested, ACS/STS presents the Home realm discovery page to the user. This page lists all the IdPs associated with the user.
·         User picks an interested IdP to be authenticated against and ACS redirects again to that IdP login URL.
·         Login Page from IdP is presented to the user to accept the user Id and password.
·         If forms authentication is set up in IdP, then a standard ASP.NET web forms login page will be shown to the user.
·         If Windows Authentication is enabled in IdP then user will be greeted with standard windows login prompt.
·         If IdP is non WS-Federation provider, then their corresponding Login pages will be displayed. For example Google, Yahoo, Facebook login pages.
·         In either case, once the user enters valid credentials, the IdP will generate the security token (usually a SAML token), sign it, and send it back to ACS.
·         ACS will validate the signature and Issuer via WS-Trust standards using Windows Identity Foundation (WIF) APIs and make sure a token was issued by the trusted party and it was not tampered with over the wire.
·         If validated, ACS will run claims or protocol transformation rules, check to see if there is anything set up for the concerned IdP, regenerate the token, sign it, and send it back to the requesting browser using the Return URL set up in ACS for the RP.
·         Browser will redirect and send this token back to RP.
·         RP can validate the signature and Issuer and make sure the token was issued by the trusted party and it was not tampered with over the wire.
·         If validated, WIF APIs will grab claims out of the token and create an HTTP context user and Claims Principal containing all the claims.
·         At this point in time, user is authenticated for this RP. Further RP can then look into the claims and provide authorization in the application.

Future Posts

This blog post is high level in nature, and in future posts, I will go into further details about the components/products mentioned in this blog post, such as:

  • Web Application Set-Up as RP using WIF with ACS/STS
  • ACS
  • ADFS
  • Active Federation

Reference Links:

  • An Introduction to Claims

           http://msdn.microsoft.com/en-us/library/ff359101.aspx

  • Federated Identity with Windows Azure Access Control Service

           http://msdn.microsoft.com/en-us/library/hh446535.aspx

  • Federated Identity with Multiple Partners and Windows Azure Access Control Service

          http://msdn.microsoft.com/en-us/library/hh446534.aspx

  • Active Directory Federation Service

          http://en.wikipedia.org/wiki/Active_Directory_Federation_Services

If you’d like to learn about our Connected Systems practice at Neudesic, please visit this page: http://www.neudesic.com/What/Expertise/Pages/ConnectedSystems.aspx

 

 

 

 

 

BISM Tabular Security

I have been focused on the security options within SSAS Tabular models lately and I have found a few ways to approach it. There is straight forward AD roles tied to a specific link to the data, but this is not very dynamic in nature and all of these roles must be hard coded to a specific row level item such as region or division. In the dynamic variety two are fairly well documented and the third is my own hybrid of the two solutions, which I will go in to detail to explain. Before I get into these I will detail out some of the general concepts.

First and foremost there is roles based security within the tabular models, but don't confuse that with dynamic security using AD roles. There is a bit of a disconnect amongst these two things when trying to create dynamic security roles. When using straight hard coded roles such as and AD group tied to a specific division this works like a charm. Most folks do not want to maintain this type of structure when you grow past just a handful of rows to maintain though. For the most basic types of security go through the lesson 12 in the Tabular Modeling segment of the Adventure Works Tutorial.

 

This leads us to a few more dynamic ways of doing this and the main issue you run into here is that to do so you must tie the row-level data back to a user by using the USERNAME() function within DAX.  This forces your role level permissions to be managed at the user level.  You can still tie specific roles to have membership to the role you are defining by allowing AD Roles in the membership, but when you start tying the data back dynamically it is forced down to the user.

 

First of the dynamic options is the method that MS shows you to use in the MSDN supplemental lesson Implement Dynamic Security by Using Row Filters.  In this lesson it details how you would tie a user in your AD to a single record type in the dimension you are working with.  The first thing I did was figure out a way to tie this to more then one table and also more then one type of record in each table.  So to go into more detail you can tie a user to not only one territory, but many by adding more records into the same table with additional 'Employee Security'[Sales Territory Id]'s, which doesn't even require a different DAX statement as they showed in there. That statement is…

 

='Sales Territory'[Sales Territory Id]=

LOOKUPVALUE('Employee Security'[Sales Territory Id],

   'Employee Security'[Login Id],

   USERNAME(),

   'Employee Security'[Sales Territory Id],

   'Sales Territory'[Sales Territory Id])

 

Essentially this DAX statement is returning a Boolean value of True or False.  So the first item shown is the 'Sales Territory'[Sales Territory Id] that is basically calling our which column in the 'Sales Territory' table this is going to be checking against on a per record basis.  Then there is an equal sign to kick get to the latter part of the logical test, which in this case is looking up what the 'Employee Security'[Sales Territory Id] is that is defined in the 'Employee Security' table.  The last 4 values actually consist of two paired values that do the lookup checks on the 'Employee Security' table and check the value against the values you would like to match it to.  Starting with the first one it looks up the 'Employee Security'[Login Id] to match it with the logged in user within AD using the USERNAME() function.  The second checks to make sure the row within the 'Employee Security' table matches the records within the 'Sales Territory' table.  When using this it is not tied to a single record within the 'Employee Security' table and will allow you to have a single employee listed more then one time with more then one [Sales Territory Id].  Thus allowing different territories and a duplicated user within different records in that table to be referenced with this same statement, cause often times I can see the need for more then one territory to be allowed for various users that can be at the regional management level where they may manage multiple territories.

 

I also thought that this can become even more complicated when you also tie it to some other table as well, especially to do data management on this table.  So by adding another column to the 'Employee Security' table you can also add in security on the 'Product Category' table as well.  So I added another column with the name [Product Category Id] that will tie back to the column 'Product Category'[Product Category Id].  This will be used in a second DAX statement within the same role, although this will sit the Row Filter for 'Product Category' table.

 

='Product Category'[Product Category Id]=

LOOKUPVALUE('Employee Security'[Product Category Id],

   'Employee Security'[Login Id],

   USERNAME(),

   'Employee Security'[Product Category Id],

   'Product Category'[Product Category Id])

 

When I looked at all of this and also thought about managing the data within the 'Employee Security' I started to think there must be a better way to handle this.  So I used a technique that will allow you to make the table more generic and then use key name and key pairs tied to users' [Login Id] field.  Instead of the table that was recommended within the lesson on MSDN above, you can user the following structure instead.

  

CREATE TABLE [dbo].[DimSecurity](

[LoginID] [nchar](50) NULL,

[KeyName] [nchar](20) NULL,

[Key] [tinyint] NULL

) ON [PRIMARY]

 

GO

 

Fill in the table with values that tie to the security you created above.  This would mean you fill in the first column with the 'Employee Security'[Login Id] and the third would use either 'Employee Security'[Sales Territory Id] or  'Employee Security'[Product Category Id]. The new column in the middle is the trick here that allows you to use this generic table approach and this would require a text field based on the name of the key you are tying it back to.  In the cases here it would be "Sales Territory Id" and "Product Category Id" respectively.

 

LoginId

KeyName

Key

domain\user1

Sales Territory Id

1

domain\user1

Sales Territory Id

2

domain\user1

Product Category Id

1

domain\user1

Product Category Id

2

domain\user1

Product Category Id

3

domain\user1

Product Category Id

4

domain\user2

Sales Territory Id

1

domain\user2

Sales Territory Id

2

domain\user2

Sales Territory Id

3

domain\user2

Sales Territory Id

4

domain\user2

Sales Territory Id

5

domain\user2

Product Category Id

1

 

 

You would use the trio of values to tie back the different Row Filters by creating the following statements within the new Role.  First let's start off with the Sales Territory Row Filter by adding the following DAX statement to that filter first.  The difference here is that you now also use the 'DimSecurity'[KeyName] paired with "Sales Territory Id" in the LOOKUPVALUE function to pair the proper valued pairs from the 'DimSecurity' table first. 

 

='Sales Territory'[Sales Territory Id]=

LOOKUPVALUE('DimSecurity'[Key],

            'DimSecurity'[LoginID],

            USERNAME(),

            'DimSecurity'[KeyName],

            "Sales Territory Id",

            'DimSecurity'[Key],

            'Sales Territory'[Sales Territory Id])

 

You will also need to do the same on the Product Category Row Filter as well to get the same results as we got in the previous example.

 

='Product Category'[Product Category Id]=

LOOKUPVALUE('DimSecurity'[Key],

            'DimSecurity'[LoginID],

            USERNAME(),

            'DimSecurity'[KeyName],

            "Product Category Id",

            'DimSecurity'[Key],

            'Product Category'[Product Category Id])

 

Now that you have both in you can go and test it out using the "Analyze in Excel" option.  I think the generic table is a bit more flexible then the option provided in the MSDN post mentioned, mostly due to the ability to manage the data in the security table much easier then if you had both [Sales Territory Id] and [Product Category Id] columns in that same dataset all tied to one user, because in this model you would still have to also add multiple records for each user to tie out every combination of the allowed rows in that table.

 

So this also leads me to a post by Teo Lachev that details out how you can use a factless fact bridge table to do something very similar to the approach I have come up with.  Not wanting to steal anything away from Teo go ahead and read that post here.

 

I don't feel any option here is perfect and will fix all your needs, but one of these options listed should get you to where you need to be. 

Posted: May 10 2012, 09:09 by Tom.Marek | Comments (0) RSS comment feed

Tags: , , , , ,
Categories: Business Intelligence

Tags

Categories

Archive

Blogroll

Neudesic Social Media

Follow Neudesic on Twitter Follow Neudesic on Facebook Neudesic Neudesic