Windows Azure Pack Authentication Overview
Applies To: Windows Azure Pack
Windows Azure Pack for Windows Server uses claims based authentication to grant access to the management portal for administrators, the management portal for tenants and the Service Management REST API. This section provides an overview of how Windows Azure Pack implements claims based authentication. The Windows Azure Pack Developer Kit includes a sample, SampleAuthApplication, that demonstrates how to authenticate to the Windows Azure Pack Admin and Tenant portals. For more about Windows Azure Pack and authentication, see https://go.microsoft.com/fwlink/?LinkId=331159.
Overview
The Windows Azure Pack management layer provides extensive REST API and a wide range of Windows PowerShell cmdlets that provide programmatic access to control and operate the admin management components.These APIs and cmdlets require the caller to be authenticated by providing a security token, signed by a trusted source. In claims based authentication, this token is provided by an external entity known as a Security Token Service (STS). A trust relationship is established between Windows Azure Pack, which is referred to as a Relying Party (RP), and a STS which allows the STS to sign security tokens and also allow Windows Azure Pack to verify the authenticity of tokens.For the STS to issue a token, it needs to first verify the user’s identity. This can be done by receiving a trusted signed token from a different trusted STS (in the case of federation), guaranteeing the user’s identity. Alternatively it can be done by consulting an entity called an Identity Provider (IdP), which knows how to interact with users and authenticate their identities.
It is possible to create different topologies in a Windows Azure Pack deployment.
Example - One
The management portal for tenants can be configured to trust the Windows Azure Pack Tenant (Membership) Authentication Site and the management portal for administrators can be configured to trust the Windows Azure Pack Admin (Windows) Authentication site. In this example, the Windows Azure Pack Tenant (Membership) Authentication Site is acting as an IdP/STS. It is an IdP because it can verify usernames and passwords against a membership store and it is an STS, because after verifying the user identity, it can issue and sign a security token that identifies the user. This also applies for the Admin Authentication Site.
Example - Two
The management portal for administrators and the management portal for tenants can be configured to trust Active Directory Federation Services 2.0 for Window Server 2012 R2 (AD FS 2.0) This is the recommended topology for production scenarios.
It is possible to configure AD FS 2.0 to authenticate users by their Active Directory (AD) credentials. In this scenario, AD is playing the IdP role and AD FS 2.0 is playing the STS role. Together they form the IDP/STS functionality.
It is possible to configure AD FS 2.0 to federate with an external STS. In this scenario, AD FS 2.0 is playing the STS role.
The chain of trust between Windows Azure Pack and the final IDP can be very long. The chain can have an unlimited number of STSs in between Windows Azure Pack (as the RP) and the final IdP.
To authenticate a user, the user needs to go to the very last IDP/STS to provide his credentials. In return he/she gets a token. The token needs to be exchanged for a new token by every STS in the trust chain and finally, the token issued by the last STS can be presented to Windows Azure Pack.
Supported Identity Providers
With Windows Azure Pack you can use any STS that can satisfy the following conditions:
Support WS-Federation
Exposes a Federation Metadata endpoint
Be capable of generating JWT tokens with at least ‘UPN’ and optionally ‘Groups’ Claims
Important
This applies only to the first STS in the chain (closest to Windows Azure Pack). Further nodes in the chain do not need these requirements. They should just be able to interact with the previous and next nodes in the Trust Chain.
Example usage of a third-party identity provider is documented at Windows Azure Pack Third Party Identity Providers.
Out-of-the-box, Windows Azure Pack for Windows Server ships with two kinds of STS.
Tenant Authentication Site
Admin Authentication Site
Active Directory Federation Services 2.0 for Window Server 2012 R2 can be used to provide identities with Windows Azure Pack. Earlier versions of AD FS are not compatible, as they do not generate JWT tokens. The Windows Azure Pack installation Guide has more information on how to federate AD FS 2.0 with Windows Azure Pack. Third Party Identity Providers can be used to provide Identities to Windows Azure Pack by federating with AD FS.
For more information about configuring AD FS 2.0 and Windows Azure Pack, see https://technet.microsoft.com/en-us/library/dn296436.aspx.
Tenant Authentication Site
The Tenant Authentication Site is an ASP.Net Membership Provider based idP/STS. The tenant user enters his or her username and password on the login page. These are then verified in the ASP.Net Membership Provider database. The Membership provider has a STS head over it which is capable of validating the user and issuing signed JWT security tokens for authorized users. It supports the WS-Federation protocol: Passive Requestor Profile XE " WS-Federation Protocol: Passive Requestor Profile " (authentication through the browser) and WS-Trust Protocol: Active Requestor Profile XE "WS-Trust Protocol: Active Requestor Profile" (authentication through Smart Clients).
Admin Authentication Site
The Admin Authentication Site is a Windows Authentication (Kerberos/NTLM) based STS which picks up the currently logged-on user’s credentials and issues signedJWT security tokens for authorized users. It supports the WS-Fed protocol for Passive flows (authentication through the browser) and WS-Trust Protocol for Active flows (authentication through Smart Clients).
Warning
Although theoretically these two STSs can be used interchangeably, the Admin and Tenant Authentication Sites should be used only for the Admin and Tenant Sites respectively. Interchanging this arrangement will cause tenant scenarios to break. In production deployment scenarios it is highly recommended to that AD FS is used.