e-SUAP - Security - Windows azure access control list (english version)
0 likes382 views
ACS is an Azure service that provides easy authentication for web applications without requiring developers to build authentication logic. It supports popular identity providers like Microsoft, Google, and Facebook, and integrates with Active Directory. ACS uses claims-based identity to get user information and uses a rule engine to transform claims between identity providers and applications.
e-SUAP - Security - Windows azure access control list (english version)
- 1. Windows Azure Access Control List During the implementation of the project e-SUAP was tested technology of windows Azure ACS for security management which ended up being very interesting. Most developers are not identity experts and do not want to spend time developing authentication and authorization mechanisms for their applications and services. ACS is an Azure service that provides an easy way for you to authenticate users to access your web applications and services without having to add complex authentication logic to your code. The following features are available in ACS: Integration with Windows Identity Foundation (WIF). Support for popular web identity providers (IPs) including Microsoft accounts (formerly known as Windows Live ID), Google, Yahoo, and Facebook. Support for Active Directory Federation Services (AD FS) 2.0. An Open Data Protocol (OData)-based management service that provides programmatic access to ACS settings. A Management Portal that allows administrative access to the ACS settings. Concepts ACS is built on the principles of claims-based identity -- a consistent approach to creating authentication mechanisms for applications running on-premises or in the cloud. Claims-based identity provides a common way for applications and services to get the identity information they need about users inside their organization, in other organizations, and on the Internet. To complete the tasks in this guide, you should understand the following terms and concepts are used in this guide: Client - A browser that is attempting to gain access to your web application. Relying party (RP) application - Your web app. An RP application is a website or service that outsources authentication to one external authority. In identity jargon, we say that the RP trusts that authority. This guide explains how to configure your application to trust ACS. Token - A user gains access to an RP application by presenting a valid token that was issued by an authority that the RP application trusts. A collection of security data that is issued when a client is authenticated. It contains a set of claims, which are attributes of the authenticated user, such as a user's name or age, or an
- 2. identifier for a user role. A token is digitally signed so its issuer can be identified and its content cannot be changed. Identity Provider (IP) - An authority that authenticates user identities and issues security tokens, such as Microsoft account (Windows Live ID), Facebook, Google, Twitter, and Active Directory. When ACS is configured to trust an IP, it accepts and validates the tokens that the IP issues. Because ACS can trust multiple IPs at the same time, when your application trusts ACS, you can your application can offer users the option to be authenticated by any of the IPs that ACS trusts on your behalf. Federation Provider (FP) - Identity providers (IPs) have direct knowledge of users, authenticate users by using their credentials, and issue claims about users. A Federation Provider (FP) is a different kind of authority. Instead of authenticating users directly, the FP brokers authentication. It acts as an intermediary between a relying party application and one or more IPs. ACS is a federation provider (FP). ACS Rule Engine - Claims transformation rules convert the claims in tokens from trusted IPs so they can be used by an RP. ACS includes a rule engine that applies the claims transformation rules that you specify for your RP. Access Control Namespace - Provides a unique scope for addressing ACS resources within your application. The namespace contains your settings, such as the IPs you trust, the RP applications you want to serve, the rules that you apply to incoming tokens, and it displays the endpoints that the application and the developer use to communicate with ACS. The following figure shows how ACS authentication works with a web application:
- 3. The client (in this case, a browser) requests a page from the RP. Since the request is not yet authenticated, the RP redirects the user to the authority that it trusts, which is ACS. The ACS presents the user with the choice of IPs that were specified for this RP. The user selects the appropriate IP. The client browses to the IP's authentication page, and prompts the user to log on. After the client is authenticated (for example, the identity credentials are entered), the IP issues a security token. After issuing a security token, the IP directs the client to send the security token that the IP issued to ACS. ACS validates the security token issued by the IP, inputs the identity claims in this token into the ACS rules engine, calculates the output identity claims, and issues a new security token that contains these output claims. ACS directs the client to send the security token that ACS issued to the RP. The RP validates the signature on the security token, extracts claims for use by the application business logic, and returns the page that was originally requested.
- 4.
- 6. The namespace NET Framework 4.5 for the management of the claims within the application code, in the case of a NET application, is System.Security.Claims. http://msdn.microsoft.com/it-it/library/system.security.claims(v=vs.110).aspx