Claims-based security and multitenancy using Windows Azure Access Control Service

Transcription

1 Shahin Dohan Claims-based security and multitenancy using Windows Azure Access Control Service Helsinki Metropolia University of Applied Sciences Bachelor of Engineering Information Technology Final Year Project 14 April 2013

2 Abstract Author(s) Title Number of Pages Date Shahin Dohan Claims-based security and multitenancy using Windows Azure Access Control Service 33 pages + 2 appendices 14 April 2013 Degree Bachelor of Engineering Degree Programme Information Technology Specialisation option Instructor(s) Software Engineering Olli Hämäläinen, Senior Lecturer Tuomas Tolvanen, Project Supervisor The goal of the project was to outsource authentication, implement resource authorization logic, and add multitenancy support using the principles of claims-based identity with the help of the Windows Azure Access Control Service (ACS). The work was implemented in an ASP.NET MVC4 application, using the C# programing language and.net framework. Development was done on the Visual Studio 2012 Integrated Development Environment (IDE). The result of the project was a fully multitenant web application with authentication logic outsourced to external services, authorization logic to protect user resources, and an authorization management page for the users to configure their resource permissions. The project was a success and is being actively developed and tested to meet customer requirement changes. Keywords Azure, claims, identity, access control service

3 Contents 1 Introduction 1 2 Windows Azure Platform Overview Windows Azure operating system SQL Azure Windows Azure Service Components (AppFabric) 6 3 Claims-based Identity Concepts and Terminology Overview 10 4 Claims-based Identity in Windows Azure and.net Windows Azure Access Control Service Windows Identity Foundation 15 5 Implementation Authentication Registration and Logging in Authorization 26 6 Discussion 31 7 Conclusions 32 References 33 Appendix 1: Custom claim handler for user resource authorization permissions Appendix 2: SAML2 Token response example from an Identity Provider

4 List of Abbreviations ACS API ASP CAM FP IIS IdP JWT MVC RDBMS REST RP SAM SAML SQL SSO STS SWT UPN WCF WIF WSFAM XML Access Control Service Application Programming Interface Active Server Pages Claims Authentication Manager Federation Provider Internet Information Services Identity Provider JSON Web Token Model View Controller Relational Database Management System Representational State Transfer Relying Party Session Authentication Module Security Assertion Markup Language Structured Query Language Single Sign-On Security Token Service Simple Web Token User Principal Name Windows Communication Foundation Windows Identity Foundation WS-Federation Authentication Module Extensible Markup Language

5 1 1 Introduction The goal of this project was to implement a multitenant cloud-based ASP.NET MVC4 web application where user authentication would be outsourced to external services, meaning users could use their existing accounts (e.g. Google) to log into the system. Authentication is only the first step though, since the application requires authorization logic that will restrict users from either viewing or modifying certain resources. Also it will require authorization logic to separate users from each other, which is what is meant by multitenancy. As an example, such an application could be a web application where customers from different companies can log in and manage employee information. Each customer should be able to log in using their existing Google or Active Directory accounts, and only be able to see information about their own employees and company. Also, all employees should be able to log in and modify some of their own information, and administrators should be able to modify any employee s information. Implementing such a system can be very complicated because of the need to support many different customers accessing our system who may be using different methods of authentication. This is what the concept of claims-based identity aims to solve; to abstract away the method of authentication from the application, thus allowing us to easily support multiple customers using different authentication methods without having to implement any authentication logic for any specific service in our application. Not only does this solve the need to support a diversity of authentication methods, but it completely lifts the burden of authentication away from the application, which in turn means that the user does not have to create a separate account and remember yet another password for a new service. Claims-based identity is the modern approach to handling user authentication, and we already see it in action in many places on the web. For example Yahoo! allows the user to login using their Facebook or Google accounts, and the Stack Exchange network allows the user to login using at least ten other types of services, as well as the traditional way of creating yet another new account for this particular service.

6 2 This is only the beginning though, since after outsourcing authentication we will have to implement authorization logic in order to protect customer resources and separate customers from each other. This can also be done with the help of claims since the idea itself does not specify anything about authentication or authorization but it is only a specification that tells how to handle user identity between systems. Authorization basically means What the user can do, and since our authorization logic is in the context of resources, this means we have to give users permissions to these resources. It means we either want the user not to see them at all, able to read them only, or have complete access and being able to modify and delete them. Authorization happens based on the user s identity, and the user s identity is transferred in the form of claims issued by a trusted entity such as Google. It is not enough to have the identity of the user only, since this does not tell us what kind of authorization permissions the user should have. The resources that are to be protected contain a list of users and their corresponding roles. Based on those rules, when the user logs in, he is given claims that are then shared across the application. Then upon accessing these resources, the system checks if the user has the claims required in order to perform some specific action on this resource. The resource always has at least one user configured as an administrator, and that is the creator and owner of that resource, who then can specify more users who are able to use this resource and to which extent. To give an example, a user authenticates to a system that manages photo albums, and they create a new album to upload pictures to. When the album is created, the user is immediately added to the list of authorized users (with the role of the owner) and is given the claim which gives the user full access to the album. Nobody else who logs into the system can see this album, but the owner of the album can manage a list of users who are allowed to see this album, then proceeds to add some other user to the list of authorized users for this album with the role of User. Then the person who was given authorization permissions by the owner, upon refreshing the page, immediately sees the photo album, and what they are allowed to do with that album depends on the role given to them, which in this case is a regular User who has read-only rights.

7 3 2 Windows Azure Platform Overview Windows Azure is a cloud platform created by Microsoft, it consists of various services and components that allow the hosting of web applications and services in Microsoft datacentres across the globe. It allows developers to easily and quickly deploy.net applications straight from Visual Studio, by using a deploy script, or from the web via the Azure portal, without having to worry about hardware and software provisioning on the cloud side. The core components of the Azure platform can be broken down into three main components: Windows Azure operating system, SQL Azure, and Windows Azure Service Components (AppFabric). The third component is no longer called the AppFabric, and the services in it are separate, but for the sake of clarity I will still group these services into a component that I will call Service Components. [1, 11] Figure 1 - Windows Azure platform core components Figure 1 shows the components and subcomponents that together make up the Azure platform. These components will be briefly covered next in order to provide a basic understanding of the Azure platform architecture.

8 4 2.1 Windows Azure Operating System The Windows Azure operating system provides all the necessary features for hosting services in the cloud: a runtime environment, background, storage and queue services, and load balancers among other components. Windows Azure also provides a local development runtime environment using an emulator that integrates seamlessly with Visual Studio. This gives the possibility to test applications before they are deployed to the cloud. The three main subcomponents of the Windows Azure operating system are: Compute, Storage, and Management. Compute The compute service offers scalable hosting of services on 64-bit versions of Windows Server 2012 (at the time of this writing). It is designed to scale dynamically based on demand, and runs the Internet Information Server (IIS) for ASP.NET web applications. It also allows executing start-up tasks, for example to install libraries or third-party components. This is the main component for actually running cloud applications. [1, 15]. Storage There are three types of storage services available in Azure: tables, blobs and queues. All of these services can be directly accessed through a REST API. Tables are non-relational (NoSQL) databases that provide a structured data storage using an independent data model known as the entity model. Blobs are designed to store large sets of binary data such as videos and images. Queues are the asynchronous communication channel between services and applications or other services. [1, 15]. Management The management component refers to the Service Management REST API exposed by Azure that allows programmatic control over the provisioning of cloud instances. Normally the web portal is used for configuring cloud instances, and for most cases that is enough, but when dealing with automatic deployments and configurations of thousands of instances, then a programmatic approach makes it easier to control these large numbers of instances.

9 5 2.2 SQL Azure SQL Azure is a relational database service within the Windows Azure platform that provides core relational database management system (RDBMS) capabilities as a service, and it is built on the SQL Server product code. Although this is a core component in the Azure platform, it is not necessary for running applications in the cloud, since Windows Azure supports non-relational storage services as seen in section 2.1. SQL Azure can be split into the following five subcomponents that will be briefly explained: Relational Data Storage, Data Sync, Management, Data Access, and Reporting Services. Relational Data Storage engine is based on the core SQL Server codebase. This component serves as the backbone of Azure SQL, providing traditional SQL Server capabilities such as tables and indexes. [1, 29] Data Sync provides the synchronization and aggregation of data to and from SQL Azure to enterprise, workstations, partners and consumer devices using the Microsoft Sync Framework. [1, 29] Management provides automatic provisioning, metering, billing, load-balancing, and failover and security capabilities for SQL Azure, and replicates the database to one primary and two secondary servers in case of a failover. [1, 29]. Data Access defines different methods for accessing SQL Azure programmatically. Currently SQL Azure supports Tabular Data Stream (TDS) which includes ADO.NET, Entity Framework, ODBC, JDBC and LINQ clients. [1, 29-30]. Reporting Services provides developers with the ability to publish, view and manage operational reports that display data from SQL Database data sources. [1, 30].

10 6 2.3 Windows Azure Service Components (AppFabric) The component that is called Service Components, previously known as the AppFabric although that term is no longer used by Microsoft, is a component that refers to a collection of services that behave as middleware in the Azure platform, effectively gluing the system together by providing services to handle user identity, caching, and message queues between applications in and outside the cloud. The services that make up this component are separate services, but grouped into this component for a clear distinction of what services make the actual platform run (Azure operating system) and what services connects the various components in the platform together to create the cloud experience. Each of these components will be briefly covered next. Access Control service provides rules-driven, claims-based access control for Azure applications. It is designed to abstract away the authentication logic from the application. It provides identity federation mechanisms, and can do claims transformations from identity providers to relying party applications. [1, 30]. This is the component that we are most interested in, because it is responsible for much of the hard work in allowing us to outsource authentication to various different services that live outside the cloud. Service Bus messaging infrastructure based on the Windows Communication Foundation (WCF) programming model that allows message delivery supporting a range of standard protocols (For example REST and AMQP) between applications in the cloud and on-premises. Caching The caching service provides distributed caching for applications running in Windows Azure, increasing performance by temporarily storing information in-memory. Caching may also help reduce the cost of database transactions by caching the data inmemory, or improving application user-friendliness by caching user session states.

11 7 3 Claims-based Identity This chapter will give the theoretical background to this project, which is the concept of claims-based identity. First and foremost, it is important that the reader is aware of all the Identity lingo used throughout this document. Otherwise it will be difficult to understand the theory. 3.1 Concepts and Terminology Subject/Principal Subject or principal refers to a user, but could also be some other non-human entity like a device or a service. The term subject is often used in security literature, and it makes sense since the user is the subject of authentication or identification. The term principal is used in.net to refer to the user. Claim A claim is a statement or an assertion made about a user, by another entity that could be another subject, but is often a service as Google. Claims are the core concept in claims-based identity, and they are the way in which the user s identity is passed between systems, that is, in the form of claims. Claims Provider A claims provider is simply an entity that provides other entities with claims asserted about a user. This term is rarely used since it is often overridden by a more specific term about the entity providing the claims. Identity Provider (IdP or IP) Identity Providers are a type of claims providers, and as the name suggests, they provide our application with the user s identity in the form of claims. This is where user authentication occurs, and the user s identity is established, so this is another integral part of a claims-based system.

12 8 Relying Party (RP) Relying Party refers to an application that relies on claims issued by a claims provider (such as an Identity Provider) in a security token. Throughout this document, when referring to the application to be developed, an application is synonymous with Relying Party. Other synonyms include Claims-aware application and Claims-based application. Issuer Issuers are simply entities that issue tokens containing claims, such as the Identity Provider. The ACS is also an issuer, the main issuer from the application s point of view in fact, because the token that the Identity Provider sends is processed by the ACS that then sends its own token. So both entities are issuers. Security Token Service (STS) The Security Token Service refers to the mechanism that accepts requests, and creates and issues tokens that contain claims (according to some protocol, such as WS- Federation). The STS is the interface within Issuers like the ACS or some Identity Provider for retrieving user identity. However they are usually hidden in diagrams, unless there is a reason to explicitly mention them. Single Sign-On (SSO) Single sign-on is the mechanism whereby a single action of user authentication can permit a user to access all systems that he or she has access to, without needing to enter the password every time. [2]. Identity Federation Identity Federation is the term to describe the exchange of user identity across different systems securely, to provide a single sign-on experience. Federation Provider (FP) The Federation Provider is the name of the service/component that provides Identity Federation. In the context of this project, and Azure systems in general, the ACS is the entity that handles Identity Federation.

13 9 WS-Federation WS-Federation is a specification that describes complex security scenarios, such as sharing identity using different mechanisms or allowing federation using different types of security tokens. It does not specify primitive operations such as requesting and receiving tokens, because those are specified in the WS-Trust specification, and WS- Federation builds on top of that and other WS-* specifications. WS-Federation commonly refers to the protocol implementation based on the specification. In the case of Microsoft it is implemented in the Windows Identity Foundation (WIF) library and is used as a language for identity federation between systems by almost every service that deals with such scenarios. SAML 2.0 SAML can either refer to the protocol, sometimes written as SAML2P, or it can refer to the SAML 2.0 token format which is the most common usage of the term. In most cases, especially with Microsoft technologies, SAML often refers to the token format which is actually supported and used by the WS-Federation protocol. [3]. The SAML protocol is widely used and supported by services such as Google, and some Microsoft services such as Active Directory Federation Services (ADFS). Surprisingly it is not supported by the WIF library out of the box, for reasons unknown. There are extensions for the WIF library available to add SAML protocol support that can be downloaded from Microsoft, though it has been frozen in a preview state since 2011 and is showing no signs of activity and should be avoided. From this point on, SAML will refer to the SAML token format and not the protocol unless explicitly stated. We do not have to worry about the protocols and token formats used by the frameworks and services provided by Microsoft, but it is good to be aware of the underlying technology that is being used. Appendix 2 provides an example of a SAML2 token response from an Identity Provider.

14 Overview Claims-based identity commonly refers to a method applications use to acquire user identity information, and although the concept is relatively new in the IT industry, it has actually been around since before computers even existed. The idea behind claimsbased identity is that the user s identity is established via claims made about the user by a trusted entity, which is usually the Identity Provider, but not necessarily as they can be made by any entity. The key here is whether we trust this entity or not. Claims can hold any type of information, ranging from a simple true or false statement regarding authentication or the full name or address of the user. The types of claims that are issued depend on the Identity Provider s security policy, and the types of claims expected depend on the Relying Party s security policy, which are often publicly exposed. In order to better illustrate the idea of claims-based identity, let us take a real life example of a user who wants to purchase alcohol from a liquor store. A customer enters a liquor store hoping to purchase alcohol, but the store s security policy states that the customer must be 18 years of age or more. In order to prove his identity and age, the customer presents the store clerk with his driver s license as a proof. The clerk checks the driver s license, and even though all the checks pass, the license seems to be expired. Therefore authorization fails because of the store s security policy and the user is required to update his driver s license. The customer then goes to the police station, gives his old license in exchange for a new one, then goes back to the liquor store presenting the clerk with his new license, and now authorization succeeds. In this example, the liquor store was the Relying Party, the police station was the Identity Provider, and the driver s license was the security token containing claims issued by the Identity Provider.

15 11 The example scenario is illustrated figure 2: Figure 2 - Claims-based Identity in real life The flow of authentication and authorization in figure 2 is as follows: 1. The customer authorization fails due to an expired driver s license. 2. The store (RP) redirects the user to the police station (IdP) to update the license. 3. The police station provides the customer with an updated license. 4. The customer presents a new license to the store clerk, and authorization passes. The application developed in this project that requires authentication outsourcing, is called the Relying Party. It is used interchangeably with application and is synonymous with Claims aware application and Claims-based application, meaning that the application authenticates users based on claims provided by a trusted Identity Provider. The key entity here is the Identity Provider that our application trusts, since that is where the authentication mechanisms are. Developing such a system on the principles of claims-based identity greatly simplifies handling user identity, since the application never has to deal with the actual authentication logic, but only needs to process the claims made about the user in the token that was issued by the trusted Identity Provider.

16 12 4 Claims-based Identity in Windows Azure and.net 4.1 Windows Azure Access Control Service The Windows Azure Active Directory Access Control Service (or just Access Control Service or ACS), is a service built on the principles of claims-based identity. It lives within the Windows Azure platform and allows applications to acquire the user s identity in a consistent way. The ACS allows users to authenticate using different methods, but from the application s perspective the method is always the same, and thus the ACS abstracts the authentication logic away from the application. The ACS supports a diverse set of standard protocols for authentication and identity sharing (Identity Federation). As of the time of this writing, the supported protocols are: WS-Trust / WS-Federation OAuth WRAP / 2.0 SAML [4]. Protocols are the language used for exchanging tokens across the web, and these tokens have a specific format and structure. The supported token formats in the ACS, which are used by the protocols are: JSON Web Token (JWT) Simple Web Token (SWT) SAML 1.1 / 2.0 [5]. The ACS also has a pre-configured list of popular Identity Providers: Windows Live ID (Microsoft Account) Google Yahoo! Facebook Any service that understands the WS-Federation protocol, such as ADFS, is also supported and directly configurable as an Identity Provider, provided that this service exposes the required security policy (Federation Metadata).

17 13 Figure 3 shows the architecture of the ACS, and how it interacts with the client and the Identity Providers: Figure 3 - ACS claims-based Identity model. Copied from ACS Architecture [6] As illustrated in figure 3, the client (user s browser) logs into the Identity Provider with credentials provided by the user and receives an IdP token (with claims in it). This token is then sent to the ACS, which processes it and produces its own ACS token that is sent to the client. The client then presents the application with the ACS token, and is finally authenticated to use the application. The way in which the ACS is able to retrieve user identity information from Identity Providers and then send it to Relying Party applications, is via claims that are stored in a token. Tokens are the medium for transporting user identity information, and these tokens are created by a component called the Security Token Service (STS). The STS is a component that builds, signs and issues security tokens. Any service that needs to create a security token, populate it with claims about a user, and then send it to another application, has an STS. This also means that the Identity Providers have an STS in order to create IdP tokens, although not shown in figure 3.

18 14 The reason the ACS needs an STS is because it needs to create tokens for applications using the claims it receives from the IdP token, this way the application receiving the ACS token does not need to support the authentication mechanisms used by the Identity Provders, since the ACS transforms the tokens into a single type that our application can understand. The tokens the ACS creates use the WS-Federation protocol, and the SAML2 token format, by default. This leads us to another crucial feature in the ACS, which is claims transformation. Claims transformation means that the claims the ACS gets from the IdP token (input claims) can be transformed into other types of claims with different values. This can be done using Rule Groups in the ACS portal. Rule Groups are a collection of rules, where each rule specifies what input claim to transform to what output claim. For example, if the IdP token contains a claim of the type name with the value John Doe, then the output claim in the ACS token is of the type role with the value Administrator. Figure 4 illustrates the idea behind claims mapping. Figure 4 - Claims transformation in the ACS By setting up rule groups to map claims, as shown in figure 4, the output claims in the token always have a similar structure, so the logic in our application that reads claims does not need to be IdP specific. Furthermore, we can use this method to outsource some authorization logic to the ACS, for example to give certain users administrative rights. It is also possible to authenticate directly with the ACS without any Identity Providers by using Service Identities, which are basically a username and password pair stored in the ACS. This is mainly useful when the client is a non-human entity such as a printer. However is out of the scope of this project.

19 15 Now that we have seen how the ACS works, the next subchapter will explain the technology that makes our application claims-aware, allowing it to process the claims in the tokens issued by the ACS. 4.2 Windows Identity Foundation Windows Identity Foundation (WIF) is a set of classes in the core.net framework for building claims-aware applications, It provides developers with a rich set of APIs for handling user authentication and authorization, making claims available in a clear, consistent and protocol-independent fashion. It is the component that is responsible for making the application claims-aware, allowing it to consume tokens issued by any STS given that the protocol is supported. WIF also supports a variety of standard protocols, and almost every aspect of it is configurable to allow developers to control every step of the authentication or authorization process. WIF has been designed to integrate with ASP.NET or WCF applications, and it provides various out-of-the-box mechanisms for achieving that. Technically WIF can be used in any.net application, but is only really useful in web-based ones such as ASP.NET since it can integrate seamlessly into ASP.NET s pipeline. It does not make much sense to apply the principles of claims-based identity in an application where user identity is irrelevant. For the sake of clarity and the scope of this document, from this point on WIF will be discussed in the context of an ASP.NET application only. [7, 52]. Most of the configuration of WIF happens in the application s web.config file, and the basic configuration can be automatically injected using the Identity and Access Tool provided by Microsoft in the form of a Nuget package, which will be done in the next chapter. The rest of this chapter will focus on what exactly makes WIF integrate itself into an ASP.NET application. The following snippets of XML code are taken from a claims-aware ASP.NET MVC4 applications web.config file, where WIF was injected using the Identity and Access tool. Note that the code snippets have been truncated so that they fit neatly into this document. They are only meant to show how WIF works in the context of an ASP.NET application.

20 16 First WIF s configurations are registered into ASP.NET: <configsections> <section name="system.identitymodel" type=" " /> <section name="system.identitymodel.services" type=" ", /> </configsections> Listing 1 ASP.NET configuration and namespace declaration section Then WIF s authentication modules are added to ASP.NET: <modules> <remove name="formsauthentication" /> <add name="wsfederationauthenticationmodule" type=" " /> <add name="sessionauthenticationmodule" type=" " /> </modules> Listing 2 ASP.NET module settings Aside from integrating WIF into ASP.NET, the tool also disabled other forms of authentication, namely the classic forms method of authentication. The module has already been removed as can be seen in listing 2, but in order to completely remove forms authentication the following changes are also required: <authentication mode="none" /> <!--Commented by Identity and Access VS Package--> <!--<authentication mode="forms"> <forms loginurl="~/account/login" timeout="2880" /> </authentication>--> Listing 3 ASP.NET authentication settings Now WIF has complete control over authentication and authorization handling, but before continuing with our examination of the configuration file to see how WIF is configured, the rest of this chapter will be used to briefly explain some of the essential modules in WIF that we already encountered in listing 2. WSFederationAuthenticationModule (WSFAM) is the HttpModule implementing the WS-Federation protocol, it provides the bulk of the functionality, taking care of redirecting unauthenticated requests to the IdP and processing incoming tokens at sign in time. In an ASP.NET application using WIF, this module can be configured in the <federationconfiguration/wsfederation> element. [7, 72; 90].

21 17 SessionAuthenticationModule (SAM) takes care of session management. After the token has been accepted and a session has been established, all subsequent requests mainly bypass the WSFAM and are processed by the SAM until the session expires or if an explicit sign-out is triggered by the user. The SAM is driven by the <federationconfiguration/cookiehandler> element. [7, 72; 90]. ClaimsAuthorizationModule (CAM) is not added by default by the Identity and Access tool, and hence we did not see it in Listing 2, but it is worth mentioning. This module allows us to override the ClaimsAuthorizationManager, which is triggered after authentication takes place and is the last step in the authentication process, making it perfect for implementing the custom authorization code before reaching the actual application code. Listing 4 shows the actual configuration section of WIF (some elements are removed to reduce clutter). The configuration elements mentioned above in the WSFAM and SAM modules can be seen under the <system.identitymodel.services> element. <system.identitymodel> <identityconfiguration> <audienceuris> <add value=" /> </audienceuris> </identityconfiguration> </system.identitymodel> <system.identitymodel.services> <federationconfiguration> <cookiehandler requiressl="false" /> <wsfederation passiveredirectenabled="true" issuer=" realm=" requirehttps="false" /> </federationconfiguration> </system.identitymodel.services> Listing 4 WIF configuration section in web.config <system.identitymodel> is an element which provides configuration for enabling WIF options in applications, and provides the default configurations for WIF. Here we can configure attributes such as audience uri s, trusted issuers, and certificate validation. The only value we are interested in here is the audience uri.

22 18 The <audienceuris> element basically defines a list of target applications where the token can be used. It must contain at least one value or else all tokens will fail. This is useful when a token is to be shared across multiple applications, so that it does not need to be re-issued by the STS. For example, if Application X contains Application Y in its audience uri s list, then any token issued for Application Y can be used in Application X without the need to refer to the STS for a new token. <system.identitymodel.services> provides configuration for passive federation using WIF. It configures the SAM and the WSFAM, and is basically the main configuration area of WIF. Since we are dealing with identity federation, the ACS being our Federation Provider (FP), we want to configure that rather than WIF globally. The <federationconfiguration> specifically is where we configure federation, as the name suggests. In other words, the modules we saw before (SAM and WSFAM) are configured here, although we will focus on WSFAM configuration only, which happens inside the <wsfederation> element. In that element, we have the following properties to configure federation: passiveredirectenabled controls how WIF will handle redirection. Setting it to true will cause WIF to automatically redirect unauthenticated requests to the STS. issuer holds the address of the STS where unauthenticated requests are redirected to. realm is a value, usually a url, that uniquely identifies our application in the STS; this value must be unique per Relying Party. requirehttps decides whether communications with the STS should take place over a Secure Socket Layer (SSL) protected channel.

23 19 5 Implementation 5.1 Authentication Outsourcing authentication to external IdPs is done by configuring the ACS in the cloud, and WIF locally. The authentication flow we want to achieve is illustrated in figure 5. Figure 5 - ACS Claims-based Identity Model authentication flow [8] The authentication flow in figure 4 is as follows: 1. Client connects to RP using a browser 2. RP redirects client to ACS login page, to choose an IP 3. ACS redirects user to IP login page, client logs in with his/her credentials 4. IP sends authentication token back to client 5. Client presents ACS with IP token 6. ACS processes the IP token, and produces an ACS token for the client 7. Client presents ACS token to RP, and is given access to the application

24 20 The first step to outsourcing authentication is configuring trusted IdPs in the ACS, which can be done from the Azure ACS portal. For this system we want to support the company s own Active Directory, and Google, as IdPs. The end result can be seen in figure 6 below. Figure 6 - Configured Identity Providers in the ACS As shown in figure 6, we currently have three IdPs supported in the ACS, because Windows Live ID is supported by default and cannot be removed. Although these are now configured in the ACS, they are not linked to any RP, which is what we have to do next in order to establish a trust relationship between the IdP and the RP. It is possible to manually add RPs from the ACS portal, but it is easier to use the Identity and Access tool provided by Microsoft for Visual Studio. This tool, given our ACS namespace and a management key, can automatically configure the RP in the ACS and integrate WIF into ASP.NET by modifying the web.config file. It can be downloaded from the Nuget repositories. First we need to fetch the management key for our ACS, which can be found in the Management Service section under Administration in the ACS portal. There is a default account named ManagementClient that contains a symmetric key, which along with the ACS namespace, has to be given to the tool, so that it can have access to configure the ACS.

25 21 After configuring the ACS namespace and management key, the tool will fetch the IdP s we configured earlier and allow us to link them to the current application (RP) that we are working on, as illustrated in figure 7. Figure 7 - Identity and Access Tool After accepting the changes, the Identity and Access tool will create a new RP in the ACS and link it to the IdPs, then create a default rule group for forwarding claims from the IdP to our RP. The tool will also update our application s assembly references and web.config configuration in order to integrate WIF into the ASP.NET authentication pipeline. Now every unauthenticated request to the application will be redirected to the ACS by WIF, and the user must authenticate using one of the configured IdPs: The companies internal AD, Google, or Microsoft Live ID.

26 Registration and Logging in Now that authentication is configured, the application needs to support user registration, but not in the traditional sense of the word. For our purpose, registration means that the user s public information is stored in our system, for future identification purposes and most importantly in order to allow us to configure authorization permissions for the user and store them in a database. Getting the basic user information such as name and address can be done by simply checking the claims provided by the IdP. However since we do not know which IdP the user will choose, we cannot write code to support parsing every IdP s claims since some use different types for the same value (AD uses nameidentifier for , for example) and others may not provide any useful claims at all (Microsoft Live ID for instance). The way to solve the problem of inconsistent output claim types is to create claims transformation rules in the ACS, which will ensure that the claims we expect from various IdPs all share the same claim type. The claims we will expect are: UPN (User Principal Name) First Name Last Name The purpose of the UPN is to act as a unique identifier for the user in our system. In practice it can be the same as the user s since that is also unique, but some IdPs (such as Live ID) do not even provide an claim, so a different value has to be used for identification, and the user himself has to provide an address. Adding rule groups for claims transformations can be done in the Rule Groups section under Trust relationships in the ACS portal. By default there is one group for each IdP for simply forwarding claims. Without these default rules even authentication would fail, since that itself is also a claim made by the IdP.

27 23 Figure 8 shows the end result of adding rule groups to transform the input claims of all three IdPs. The actions of each rule can be seen in the Rule Description column. Figure 8 - Rule Groups for claims mapping As can be seen from figure 8, the UPN claim is formed out of three different types of input claims depending on the IdP. We can already see how these simple rules help our implementation of authorization logic tremendously. The next step to implementing registration is to create an ASP.NET action in a public controller that parses the claims from the ACS, and then registers the user by adding them silently to the database. Although this is how the system should ideally work, some IdPs such as Windows Live ID prevent this due to the fact that it does not provide a single useful claim other than a unique identifier, which is actually not a unique claim because its value is generated depending on the ACS namespace and RP realm, making user migration extremely difficult. Since Live ID does not provide us with the basic claims for user identification, we need to prompt the user with a registration page where they can manually enter their name and address, which are then linked to the unique identifier claim and stored in the database. The downside to this is that the user can enter any they want, which means for security reasons we might need to implement validation. Ideally the system would not support Live ID at all, because it is basically useless in practice.

28 24 Listing 5 below shows how to implement an action to parse claims provided by the ACS safely, then redirecting the user to the registration page. [HttpPost] public ActionResult AuthenticateRegistration() { var user = HttpContext.User as ClaimsPrincipal; } // User should be authenticated by the IdP at this point if (!user.identity.isauthenticated) return RedirectToAction("Index", "Home"); // Fetch claim var claim = user.claims.firstordefault(c => c.type == ClaimTypes. ); // If claim was null, set value to empty string var = claim!= null? claim.value : String.Empty; var registermodel = new RegisterModel(firstName, lastname, , upn); return View("Register", registermodel); Listing 5 Claims parsing for registration Listing 5 shows the fetching of one type of claim only ( ) to avoid duplicating a similar code, but in the same way every other claim can be fetched from the user object that lives in the http request context. After the claims are parsed, the user is redirected to a registration page where the fields are filled automatically with the values from the claims, and then if the user accepts he is registered into the system. It is a good idea to have a public home page that requires no authentication, where a user can choose to either register or log in. Registration actions should check if the user is authenticated, while login actions should check if the user is authenticated and registered. Now that the user is registered, we can create our own custom claim that says that this user is registered into our system. The distinction between authenticated and registered users is an important one, because authenticated users are only able to register and view a public home page, but registered users can actually use the system, so we need a separate way by which we can tell if the user is registered or not, using custom claims.

29 25 Fortunately it is very easy to create custom claims. After the user agrees to register, we must create a custom Registered claim that the rest of the application can use to determine whether the current user is registered or not. This can be done as illustrated in listing 6. // Add claim to mark user as registered claims.add(new Claim(CustomClaimTypes.Registered, "true")); // Set new claims user.addidentity(new ClaimsIdentity(claims)); // Update session cookie var sam = FederatedAuthentication.SessionAuthenticationModule; if (sam!= null) { var token = new SessionSecurityToken(user); sam.writesessiontokentocookie(token); } Listing 6 Adding a custom claim First we create a new claim of type Registered which is our own custom type, with the value true. After the claim is created, it can be added to the user object by creating a new identity that holds those claims as illustrated in listing 6. The last part updates the session cookie of the user. If we skip this part then our changes are basically lost since all the claims live inside the token, and the token lives inside the cookie. Every time claims are added, the cookie must be updated. The next logical thing to implement is the logging in functionality, as well as logging out, which are fairly straightforward. All that needs to be done is a new action where we check for the Registered claim since that is our way of knowing whether a user can log in or not. Logging out can be implemented as illustrated in listing 7. var fam = FederatedAuthentication.WSFederationAuthenticationModule; fam.signout(true); Listing 7 Logging out As illustrated in listing 7, logging out is a trivial task, but it is important to note that this does not log the user out of the IdP but rather from the RP. What this means in practice is that the next time he decide to log in, he does not need to go through the whole authentication cycle, since the cookie that logs the user into the IdP is already present.

30 Authorization Now that authentication has been outsourced and users are able to register and log in, authorization logic must be implemented. We have technically already implemented some authorization logic with the custom Register claim, but are still missing resource authorization permissions. Since the type of data is irrelevant, let us assume the user wants to be able to create a collection of employee information objects. The kind of system we want to achieve is one where a user registers, and is immediately able to create employee information objects that nobody else is allowed to see, unless specified explicitly by the user. Before implementing authorization claims logic handling, we should protect the views and controllers from unauthorized access. The best way to achieve view protection is to extend the ClaimsPrincipal class, then use the User object from the http context, and implement if-else checks around the html elements that should be hidden. This is illustrated in listing 8. public static class ClaimsPerimissionExtensions { public static bool AuthorizeObjectAdmin(this IPrincipal principal, string objectid) { // Check if user has admin claim for this object var user = principal as ClaimsPrincipal; return (user!= null && user.identity.isauthenticated &&user.hasclaim(customroles.admin, objectid)); } } Listing 8 Extending the ClaimsPrincipal class Although protecting the views blocks unauthorized viewers from seeing content they ought not to see, it is still possible to access this data if the user knows the correct url and the object s id. This can be fixed by creating a custom authorization attribute for ASP.NET that will fetch the user object from the http context and the object id from the route data, and then call the authorization extension methods implemented in listing 8.

31 27 The custom attribute can be implemented by subclassing the ActionFilterAttribute and then overriding the AuthorizeCore method. This is illustrated in listing 9: public class AuthorizeAdmin : AuthorizeAttribute { protected override bool AuthorizeCore(HttpContextBase httpcontext) { var user = httpcontext.user as ClaimsPrincipal; var routedata = ((MvcHandler)httpContext.Handler).RequestContext.RouteData; // Fetch resource id from route data var objectid = routedata.values["customerobjectid"].tostring(); } } return user.authorizeobjectadmin(objectid); Listing 9 Custom authorization attribute The attribute in listing 9 can then be used to decorate actions that require administrator authorization. After using the attributes to protect actions, any user who logs in to the system is not able to do anything, because we have not implemented resource authorization claim handling. The first task to be done before the application code is reached, is checking the authorization permissions of the currently authenticating user. This is done by checking the permissions of the objects and then creating custom claims for that user based on the user permissions configured in the object itself. The best place to do this is in the Authenticate method, which can be overridden by subclassing the ClaimsAuthenticationManager class. This method gets triggered after the user is authenticated, and before reaching the application code, which gives the developer a good opportunity to handle custom authentication and authorization logic. It is important to mention at this point that authorization claim handling is intended to be handled by overriding the CheckAccess method in the ClaimsAuthorizationManager class which is the last method to be called in the authentication flow.

32 28 The reason using the ClaimsAuthorizationModule was a bad idea for the company s web application was mainly performance-related. Since the authorization module s CheckAccess method gets called every single time a protected resource gets accessed, if we do any database access in that method, it will hurt database performance significantly. Therefore we implement our logic in the authentication module that is triggered only once when the user is authenticated, then never again. Since we have also implemented custom attributes and user class extensions for handling authorization, there is no point in using the CheckAccess method which essentially works the same way as having a custom attribute on a protected action, except on a global application scale where resource permissions are defined in the web.config file rather than by decorating controllers and actions. The downside to not using the authorization module to implement authorization logic is that if a resource s user permissions have changed, we need some way to update the current user s claims without requiring them to log out and back in order to go through the authentication module again. Since resources were mainly accessed from a list on the home page, which itself is not accessed often, it is possible to implement a method in the index action of the home controller. There we essentially do the same task the authentication manager does, which is giving the user claims by checking the object s authorization permissions. Implementing claims handling logic in the authentication manager is done by subclassing the Authenticate method in our custom AuthenticationManager class that subclasses ClaimsAuthenticationManager. The first task to be done is telling WIF about our custom authentication manager, as illustrated in listing 10. <system.identitymodel> <identityconfiguration> <claimsauthenticationmanager type="namespace.authenticationmanager, Namespace, Version= , Culture=neutral" /> </identityconfiguration> </system.identitymodel> Listing 10 Custom authentication manager