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

Branding Guidelines for Integrated Apps

Updated: April 30, 2013

This topic discusses the branding guidelines you should use when developing integrated applications with Windows Azure Active Directory. These guidelines will help direct your customers when they want to use their company, school or other accounts (managed in Windows Azure AD) for sign-up and sign-in to your app.

Windows Azure AD Accounts vs. Microsoft Accounts

Microsoft operates two identity platform services:

  • Microsoft accounts (formerly known as Windows Live ID) represent the relationship between individual users and Microsoft, and are used to access Microsoft devices and services. They are intended for personal use.

  • Windows Azure Active Directory is an identity management service (IdMaaS) that extends Windows Server Active Directory to the cloud. It hosts user accounts that are owned and controlled by organizations.

Windows Azure AD accounts are assigned to end users (employees, students, federal employee) by their organizations (company, school, government agency). They can be created directly in Windows Azure AD, or be federated from an on-premises directory such as Windows Server AD. Microsoft is the custodian of user accounts hosted on Windows Azure AD, but the accounts are owned and controlled by the organization.

Referring to Windows Azure AD in Your Application

We recommend that developers don’t expose their end users to the Active Directory brand name. Instead, we encourage tenants of our cloud directory (i.e. organizations that sign up for Windows Azure AD or other Microsoft services for organizations such as Office 365) to promote their own corporate brand name to their users, and if possible your app should do the same. However, when the organization’s name is unknown by your app because it uses tenant-independent endpoints (for example https://www.adatum.com as opposed to https://www.adatum.com/contoso.com) you should use generic terms like “company accounts” or “school accounts” depending on the user groups your app serves.

If your app caters to Information Workers, you may want to use “company account”; if it’s specifically aimed at the educational market you can use “school accounts”. We recommend that you avoid terms like “enterprise account”, “business account” or “corporate account” which create user confusion.

Organization User Account Pictogram

Pictogram for Windows Azure AD

This pictogram (choose the size most appropriate for your app’s web site pages) represents accounts backed by Windows Azure AD. We use this pictogram extensively across the Microsoft organizational services such as Office 365 and Azure, so that end users will associate it with their organization account. This ensures that users of your app will recognize this pictogram and understand that they can reuse the account they use to sign in to their corporate network, Office 365 or other Microsoft services for organizations. You can download this pictogram and other assets shown in this document by visiting the links in the Branding Resources section.

Signing Up and Signing In with Windows Azure AD

Your app may present separate paths for sign-up and sign-in and the following sections provide visual guidance for both scenarios.

Organizations typically need to sign up or license your app before their end-users can use it. You can leverage Windows Azure AD to simplify the sign-up experience for your customers that already use Windows Azure AD, as well as the end user sign in experience:

  • Invite admins to sign up for (trial or buy) your app with their organization account. Here the admin will be taken through a grant access experience to allow their organization’s users to sign in to your app.

  • Invite end-users to sign-in to your app with their organization account, once their admin has signed up.

When addressing admins, you should use the terms described below, but it’s also fine to clarify that they need to have their organization managed on or connected to Windows Azure AD.

Visual Guidance for Sign Up

Any sign-up button or link must redirect the user to the Windows Azure AD grant access (authorize) page, to allow an organization’s administrator to authorize your app to have access to their directory. Details on how to request access are discussed in the Adding, Updating, and Removing an App topic.

Button Only

If you use buttons only, we recommend you use something similar to the buttons shown below. If you target businesses, we recommend “Connect to your company” or “Add it to your company” terminology. If you target academic institutions, we recommend “Connect to your School” terminology. If your app caters to both, you could show both as “Connect to your school or company” or “Connect to your work.”

The example HTML code snippets should be used to generate buttons based on the referenced CSS and glyphs that are most appropriate for your app. The buttons that these snippets generate are also shown below:

<html>
<head>
   <title>Azure AD Badges</title>
   <link rel="stylesheet" href="https://bposast.vo.msecnd.net/AzureAD/glyph/index.css" />
</head>
<body>

<a class="azuread azuread-large">
   <div class="azuread-glyph"><img src="https://bposast.vo.msecnd.net/AzureAD/glyph/glyphs.png" width="58" height="110" alt="Glyphs" /></div>
   <div class="azuread-content">
      <div class="azuread-content-heading">Connect to your company
         <div>No separate login required for your users<br />Free for 30 days</div>
      </div>
   </div>
</a>

<br /><br />

<a class="azuread azuread-medium">
   <div class="azuread-glyph"><img src="https://bposast.vo.msecnd.net/AzureAD/glyph/glyphs.png" width="58" height="110" alt="Glyphs" /></div>
   <div class="azuread-content">
      <div class="azuread-content-heading">Add it for your school
         <div>No separate login required for your users</div>
      </div>
   </div>
</a>

<br /><br />

<a class="azuread azuread-small">
   <div class="azuread-glyph"><img src="https://bposast.vo.msecnd.net/AzureAD/glyph/glyphs.png" width="58" height="110" alt="Glyphs" /></div>
   <div class="azuread-content">
      <div class="azuread-content-heading">Connect to your work</div>
   </div>
</a>

</body>
</html>

Visual Guidance for Button Sign Up

Button and Help Text

If you use buttons and explanation text side by side, we recommend you do something like this:

Button Sign Up for Windows Azure AD

Text Only

If you want to provide a more detailed explanation to your potential customers, we recommend adapting the following text:

If you already use Office 365, Windows Azure or other Microsoft service for organizations, you can simply grant <your_app_name> to access your organization’s directory. This will allow your users to access <your_app_name> with their existing user accounts.

Visual Guidance for Sign-In

Any sign-up button must redirect the user to one of the Windows Azure AD sign on endpoints (for SAML-P or WS-Federation, depending on the protocol your app uses) to allow an organization’s users to sign in to your app using their account. The following sections provide details on what that button should look like.

Pictogram and “your company” or “your school”

It’s the association of this trademarked pictogram and the generic organization language that uniquely represents Windows Azure AD amongst other identity providers your app may support.

Here are some sign-in button examples. You should choose the one most appropriate for your customers. The example HTML code snippets should be used to generate buttons based on the referenced CSS and glyphs that are most appropriate for your app. The buttons that these snippets generate are also shown below:

<html>
<head>
       <title>Azure AD Badges</title>
       <link rel="stylesheet" href="https://bposast.vo.msecnd.net/AzureAD/glyph/index.css" />
</head>
<body>

<a class="azuread azuread-small">
       <div class="azuread-glyph"><img src="https://bposast.vo.msecnd.net/AzureAD/glyph/glyphs.png" width="58" height="110" alt="Glyphs" /></div>
       <div class="azuread-content">
              <div class="azuread-content-heading">School account</div>
       </div>
</a>

<br /><br />
<a class="azuread azuread-small">
       <div class="azuread-glyph"><img src="https://bposast.vo.msecnd.net/AzureAD/glyph/glyphs.png" width="58" height="110" alt="Glyphs" /></div>
       <div class="azuread-content">
              <div class="azuread-content-heading">Company account</div>
       </div>
</a>

<br /><br />
<a class="azuread azuread-small">
       <div class="azuread-glyph"><img src="https://bposast.vo.msecnd.net/AzureAD/glyph/glyphs.png" width="58" height="110" alt="Glyphs" /></div>
       <div class="azuread-content">
              <div class="azuread-content-heading">Work account</div>
       </div>
</a>

<br /><br />
<a class="azuread azuread-small">
       <div class="azuread-glyph"><img src="https://bposast.vo.msecnd.net/AzureAD/glyph/glyphs.png" width="58" height="110" alt="Glyphs" /></div>
       <div class="azuread-content">
              <div class="azuread-content-heading">Sign in</div>
       </div>
</a>

</body>
</html>

Sign in Button Guidance for Windows Azure AD

You can even provide some additional explanation to end users to help them recognize whether they can use this button:

Sign In Button Guidance for Windows Azure AD

You can also use HTML to render a button without any text – i.e. pictogram only:

<html>
<head>
   <title>Azure AD Badges</title>
   <link rel="stylesheet" href="https://bposast.vo.msecnd.net/AzureAD/glyph/index.css" />
</head>
<body>

<a class="azuread azuread-small">
   <div class="azuread-glyph"><img src="https://bposast.vo.msecnd.net/AzureAD/glyph/glyphs.png" width="58" height="110" alt="Glyphs" /></div>
</a>

</body>
</html>

Sign In Options

If your app uses tenant-specific URLs (for example https://www.adatum.com/contoso.com or https://contoso.adatum.com), then it’s straightforward for your app to map this to the tenant-specific Windows Azure AD login URL you need to use to log users in from this tenant. You can see the format of tenant-specific login URLs in the Windows Azure Management Portal by clicking View Endpoints in the command bar.

If your app doesn’t use tenant-specific URLs (for example https://www.adatum.com), then Windows Azure AD provides a tenant-independent set of endpoints that your app’s sign-in button can redirect the user to for sign in without having to perform any realm discovery (asking the user for extra information that would allow you to ascertain the user’s tenant).

 

SAML-P

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

WS-Federation

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

Federation metadata

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

Branding Do’s and Don’ts

DO use “Your school”, “Your company” or “Your organization” in combination with the Active Directory user pictogram to represent user sign-ins with Windows Azure AD. For consistency, only use “Company” and “School”, and DON’T use other terms such as “enterprise”, “business” or “corporate”.

DON’T alter the Active Directory user pictogram. Using the same shape and color pictogram will help users recognize it across all cloud applications they are using.

DON’T expose end-users to the Active Directory brand. It’s ok however to use this term with Developers, IT Pros and Admins.

DON’T use “Office 365 accounts”, “Office 365 IDs”, “Windows Azure accounts”, or any such variation. These concepts don’t exist and will confuse users who may not even realize that their organization uses Microsoft’s cloud identity service (FYI, both Office 365 and Windows Azure can be accessed with either a personal Microsoft account or an organizational account backed by Windows Azure AD.)

Navigation Do’s and Don’ts

DO provide a way for users to sign out and switch to another user account. While most people have a single personal account from Microsoft/Facebook/Google/Twitter, people are often associated with more than one organization.

Supporting both Windows Azure AD and Microsoft Accounts in Your App

If your app supports both Windows Azure AD and Microsoft accounts, you should model each sign-in option independently (you can’t create a single sign-in button for “Microsoft”).

Branding Resources

Vis:
© 2014 Microsoft