Eksportér (0) Udskriv
Udvid alt
EN
Dette indhold er ikke tilgængeligt på dit sprog, men her er den engelske version.

Authentication Services Release Notes

Published: April 5, 2013

Updated: July 14, 2014

Azure Active Directory (AD) is a highly-available and highly-scalable service of 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 Azure Active Directory and provides links to topics that you can use to learn about the details.

This topic has the following sections:

Azure AD supports the WS-Federation and SAML 2.0 protocols to enable single sign-on and single sign-out. To learn more, see Azure Active Directory Authentication Protocols. We've also released our implementation of OAuth 2.0, an open standard for authorization. For more information, see OAuth 2.0 in Azure AD.

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 Azure AD and discover the tenant by parsing the token that 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 Azure Active Directory, see SAML Protocol Reference. For more information about Federation Metadata, see Federation Metadata.

The SAML tokens that 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.

The IdentityProvider claim is now included in the SAML tokens that 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>

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 Azure Active Directory technologies might encounter this change in the value of NameId element during the transition to the new claim types.

The ObjectId claim is now included in the SAML tokens that 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>

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

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

The UPN claim, http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn, is no longer included in that SAML tokens that 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.

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).

The JSON Web Tokens (JWT) that are issued from the JavaScriptNotify endpoint that 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

The idp claim is now included in the JWT tokens that 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/"

The tid claim is now included in the JWT tokens that 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"

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

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 Azure Active Directory issues.

The oid claim is now included in the JWT tokens that 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"

The sub claim, which identifies the authenticated user, is now included in the JWT tokens that 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="

The SAML endpoint and endpoints for WS-Federation and WS-Federation Metadata that 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.

ImportantImportant
If users bookmarked the 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 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

You can use an organizational account or a Microsoft account (formerly known as a "Windows Live ID") to access the Microsoft Azure Management Portal. 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.

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

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.

See Also

Vis:
© 2014 Microsoft