Экспорт (0) Печать
Развернуть все

Authentication Services Release Notes

Опубликовано: Апрель 2013 г.

Обновлено: Февраль 2014 г.

Windows Azure Active Directory (AD) is a highly-available and highly-scalable service of Windows Azure that provides identity and access management for cloud applications, including single sign-on and sign-out, Graph API, and integration with on-premises Active Directory. This topic briefly describes the new features of Windows Azure Active Directory and provides links to topics that you can use to learn about the details.

This topic has the following sections:

New Protocol Support

Windows Azure AD supports the WS-Federation and SAML 2.0 protocols to enable single sign-on and single sign-out. To learn more, see Windows Azure Active Directory Authentication Protocols. Support for OAuth 2.0, an open standard for authorization, is coming soon, but is not yet released. For more information, watch our OAuth 2.0 (Preview Version) page.

Tenant-Independent Endpoints

To improve the single sign-on experience for users of multi-tenant applications, we have implemented common or tenant-independent endpoints for single sign-on. These new endpoints eliminate the need to perform realm discovery for users. Instead, the application can direct all users to Windows Azure AD and discover the tenant by parsing the token that Windows Azure AD returns.

In each tenant-independent endpoint, "common" appears in the position in the URL in which the tenant ID or tenant URL appears in a tenant-specific endpoint.

The new tenant-independent endpoints are:

  • SAML: https://login.windows.net/common/saml2

  • WS-Federation: https://login.windows.net/common/wsfed

  • WS-Federation Metadata: https://login.windows.net/common/FederationMetadata/2007-06/FederationMetadata.xml

For more information about using SAML protocol with Windows Azure Active Directory, see SAML Protocol Reference. For more information about Federation Metadata, see Federation Metadata.

SAML Token Changes

The SAML tokens that Windows Azure AD issues have been changed. These changes are designed to make our SAML tokens compliant with the latest standards and to add value to applications that use the claims-based authentication and authorization.

The following list summarizes the SAML token changes.

  • Added

    • IdentityProvider claim

    • ObjectId claim

  • Removed

    • PUID claim

    • UPN claim

  • Changed

    • NameId element: The value of the NameId element is changed.

    • TenantId claim: The TenantId claim type is changed.

    • NameIdPolicy element: Added a new valid value.

IdentityProvider Claim

The IdentityProvider claim is now included in the SAML tokens that Windows Azure AD issues. The IdentityProvider claim, http://schemas.microsoft.com/identity/claims/identityprovider, contains information about the identity provider that authenticated the user. The value of the claim is a URL that specifies the realm (logical name) of the identity provider.

The following is a sample IdentityProvider claim.

<Attribute Name="http://schemas.microsoft.com/identity/claims/identityprovider">
<AttributeValue>https://sts.windows.net/a42e404c-4951-4b0a-9e29-f7d7b49be3ce/</AttributeValue>
</Attribute>

NameId Element

The value of the NameId element has been updated to an opaque and immutable identifier that represents the authenticated user. The NameId value is a targeted identifier that is directed only to the relying party that is the audience for the token. The value is persistent; it can be revoked, but is never reassigned. It is also opaque, that is, it does not reveal anything about the user and it cannot be used an identifier for attribute queries.

The following sample NameId element includes a value in the new format.

<NameID>Uz2Pqz1X7pxe4XLWxV9KJQ+n59d573SepSAkuYKSde8=</NameID>

Applications that use Windows Azure Active Directory technologies might encounter this change in the value of NameId element during the transition to the new claim types.

ObjectId Claim

The ObjectId claim is now included in the SAML tokens that Windows Azure AD issues. The ObjectId claim, http://schemas.microsoft.com/identity/claims/objectidentifier, contains the object ID of the user who is the token subject. Because the ObjectId value is immutable and not reusable, it is the preferred claim type for use as a security identifier in authentication.

The following is a sample ObjectId claim.

<Attribute Name="http://schemas.microsoft.com/identity/claims/objectidentifier">
<AttributeValue>3F2504E0-4F89-11D3-9A0C-0305E82C3301</AttributeValue>
</Attribute>

PUID Claim Type

The Passport Unique Identity (PUID) claim, http://schemas.xmlsoap.org/claims/PUID, is removed. It will no longer appear in the SAML tokens that Windows Azure Active Directory issues.

TenantId Claim

The TenantId claim type has been updated.

 

Old TenantId claim

http://schemas.microsoft.com/ws/2012/10/identity/claims/tenantid

New TenantId claim

http://schemas.microsoft.com/identity/claims/tenantid

UPN Claim

The UPN claim, http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn, is no longer included in that SAML tokens that Windows Azure Active Directory issues. The UPN value is available in the value of the Name claim, http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name.

NameIdPolicy Element

The emailAddress format value is valid for the optional NameIdPolicy element in AuthnRequest. A value of "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" directs ACS to issue a NameId claim with an e-mail address format.

The other valid values for the optional NameIdPolicy element are "urn:oasis:names:tc:SAML:2.0:nameid-format:persistent" and "urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified".

For more information, see Single Sign-on (SAML Protocol).

JWT Token Changes

The JSON Web Tokens (JWT) that are issued from the JavaScriptNotify endpoint that Windows Azure Active Directory uses for interactive user authentication have changed.

The following list summarizes the JWT token changes.

  • Added

    • Identity provider (idp) claim

    • Tenant ID (tid) claim

    • Object ID (oid) claim

    • Subject ID (sub) claim

  • Removed

    • Name ID (nameid) claim

    • PUID (puid) claim

Identity provider (idp) claim

The idp claim is now included in the JWT tokens that Windows Azure AD issues. This claim contains information about the identity provider that authenticated the user. The value of the claim is a URL that specifies the realm (logical name) of the identity provider.

The following is a sample idp claim.

"idp":"https://sts.windows.net/a42e404c-4951-4b0a-9e29-f7d7b49be3ce/"

Tenant ID (tid) claim

The tid claim is now included in the JWT tokens that Windows Azure Active Directory issues. The value is a GUID that uniquely identifies the tenant of the token subject.

The following is a sample tid claim.

"tid":"a42e404c-4951-4b0a-9e29-f7d7b49be3ce"

Name ID (nameid) claim

The nameid claim type is removed. The Subject ID (sub) claim identifies the authenticated user.

PUID (puid) claim

The Passport Unique Identity (PUID) claim, "http://schemas.xmlsoap.org/claims/PUID," has been removed. It will not be available in the JWT tokens that Windows Azure Active Directory issues.

Object ID (oid) claim

The oid claim is now included in the JWT tokens that Windows Azure Active Directory issues. The ObjectId claim, http://schemas.microsoft.com/identity/claims/objectidentifier, contains the object ID of the user who is the token subject. Because the oid value is immutable and not reusable, it is the preferred claim type for authentication and authorization.

The following is a sample oid claim.

"oid":"3F2504E0-4F89-11D3-9A0C-0305E82C3301"

Subject ID (sub) claim

The sub claim, which identifies the authenticated user, is now included in the JWT tokens that Windows Azure AD issues. The value of the sub claim is a targeted identifier that is directed only to the relying party that is the audience for the token. The value is persistent; it can be revoked, but is never reassigned. It is also opaque, that is, it does not reveal anything about the user and it cannot be used an identifier for attribute queries.

The following is a sample sub claim.

"sub":"Uz2Pqz1X7pxe4XLWxV9KJQ+n59d573SepSAkuYKSde8="

Endpoint Updates

The SAML endpoint and endpoints for WS-Federation and WS-Federation Metadata that Windows Azure AD uses have been changed. The current endpoint URLs will be supported temporarily to ease migration to the new endpoints, but they will be discontinued after a brief transition period.

As we complete this transition, take care not to use both old and new endpoints in the same application or in applications in the same tenant. Mixing endpoints during sign-in causes sign-out to fail. For example, if an application sends sign-in messages to one endpoint and sign-out messages to the other endpoint, attempts to sign out will fail. Similarly, if some applications in a tenant use one endpoint, and other applications in the same tenant use the other endpoint, sign-out messages will fail. If this failure occurs, you can sign out by closing the browser.

ImportantВажно!
If users bookmarked the Windows Azure AD sign-in page URL when an application was configured to use the accounts.accesscontrol.windows.net endpoint, using those bookmarks now will cause sign-in to fail. Users should clear those bookmarks and bookmark the application URL instead of the Windows Azure AD sign-in page URL.

SAML 2.0 Protocol endpoint

Old endpoint

https://accounts.accesscontrol.windows.net/<tenant>/v2/saml2

New tenant-specific endpoint

https://login.windows.net/<tenant>/saml2

New tenant-independent endpoint

https://login.windows.net/common/saml2

WS-Federation endpoint

Old endpoint

https://accounts.accesscontrol.windows.net/<tenant>/v2/wsfederation

New tenant-specific endpoint

https://login.windows.net/<tenant>/wsfed

New tenant-independent endpoint

https://login.windows.net/common/wsfed

WS-FederationMetadata endpoint

Old endpoint

https://accounts.accesscontrol.windows.net/<tenant>/federationmetadata/2007-06/federationmetadata.xml

New tenant-specific endpoint

https://login.windows.net/<tenant>/federationmetadata/2007-06/federationmetadata.xml

New tenant-independent endpoint

https://login.windows.net/common/federationmetadata/2007-06/federationmetadata.xml

Limitations of Microsoft Accounts

You can use an organizational account or a Microsoft account (formerly known as a "Windows Live ID") to access the Портал управления платформой Windows Azure. However, Microsoft accounts are currently limited in the following ways.

  • Service administrators who sign in with a Microsoft account cannot add organizational accounts as co-administrators of the subscription.

    If you sign in with an organizational account, you can add any valid organizational or Microsoft account as a co-administrator, but if you sign in with a Microsoft account, you can add only other Microsoft accounts as co-administrators.

  • Windows Azure AD currently does not allow Microsoft accounts to use single sign-on protocols for applications. To implement Windows Azure AD single sign-on in your application, use an organizational account.

Baltimore CyberTrust Certificates

Windows Azure AD will soon start using Baltimore CyberTrust digital certificates. To avoid SSL connection errors during development on client computers and during deployment of servers and cloud infrastructure, applications need to trust the Baltimore CyberTrust root certificate.

См. также

Показ:
© 2014 Microsoft