B2c Single Sign On Configuration

• B2c Single Sign-on Configuration
• B2c Single Sign On Configuration Settings
• B2c Single Sign On Configuration Yahoo Mail
• Azure B2c Single Sign On Configuration

Open System i Navigator, go to Network Enterprise Identity Mapping Configuration, right click, and select Configure: B. For new set up, select Create and join a new domain; if you have EIM configured locally or on another system already and want to use that for the mapping, select Join an existing domain. So, we needed two sign-in policies where sign-up is enabled only for the other policy. Azure AD B2C Configuration. The picture below shows the list of user flows (a.k.a. Policies) that we have set up. The “standard” sign-in policy is only a sign-in type, which does not enable signing up. I have a custom policy setup that allows users to login using B2C credentials or Azure AD as an external IdP. This works perfectly well. I am now trying to implement the 'Tenant' setting of built-in policies so that multiple apps make the users sign in only once. Single sign-on configuration - The Azure AD B2C session can be configured with the following scopes: Tenant - This setting is the default. Using this setting allows multiple applications and user flows in your B2C tenant to share the same user session. Screen Reader users press enter to select a Filter by product. Filter by product This button does not work with screen readers. Please use the previous link instead. Make selection - click arrows to drill down.

[AZURE.INCLUDE active-directory-b2c-preview-note]

This feature gives you fine-grained control, on a per-policy basis, of:

1. Lifetimes of security tokens emitted by Azure Active Directory (Azure AD) B2C.
2. Lifetimes of web application sessions managed by Azure AD B2C.
3. Single sign-on (SSO) behavior across multiple apps and policies in your B2C tenant.

You can use this feature in your B2C tenant as follows:

1. Follow these steps to navigate to the B2C features blade on the Azure portal.
2. Click Sign-in policies. Note: You can use this feature on any policy type, not just on Sign-in policies.
3. Open a policy by clicking it. For example, click on B2C_1_SiIn.
4. Click Edit at the top of the blade.
5. Click Token, session & single sign-on config.
6. Make your desired changes. Learn about available properties in subsequent sections.
7. Click OK.
8. Click Save on the top of the blade.

Token lifetimes configuration

Azure AD B2C supports the OAuth 2.0 authorization protocol for enabling secure access to protected resources. To implement this support, Azure AD B2C emits various security tokens. These are the properties you can use to manage lifetimes of security tokens emitted by Azure AD B2C:

• Access & ID token lifetimes (minutes): The lifetime of the OAuth 2.0 bearer token used to gain access to a protected resource. Azure AD B2C issues only ID tokens at this time. This value would apply to access tokens as well, when we add support for them.
  • Default = 60 minutes.
  • Minimum (inclusive) = 15 minutes.
  • Maximum (inclusive) = 1440 minutes.
• Refresh token lifetime (days): The maximum time period before which a refresh token can be used to acquire a new access or ID token (and optionally, a new refresh token, if your application had been granted the offline_access scope).
  • Default = 14 days.
  • Minimum (inclusive) = 1 day.
  • Maximum (inclusive) = 90 days.
• Refresh token sliding window lifetime (days): After this time period elapses the user is forced to re-authenticate, irrespective of the validity period of the most recent refresh token acquired by the application. It can only be provided if the switch is set to Bounded. It needs to be greater than or equal to the Refresh token lifetime (days) value. If the switch is set to Unbounded, you cannot provide a specific value.
  • Default = 90 days.
  • Minimum (inclusive) = 1 day.
  • Maximum (inclusive) = 365 days.

These are a couple of use cases that you can enable using these properties:

• Allow a user to stay signed into a mobile application indefinitely, as long as he or she is continually active on the application. You can do this by setting the Refresh token sliding window lifetime (days) switch to Unbounded in your sign-in policy.
• Meet your industry's security and compliance requirements by setting the appropriate access token lifetimes.

Session configuration

Azure AD B2C supports the OpenID Connect authentication protocol for enabling secure sign-in to web applications. These are the properties you can use to manage web application sessions:

• Web app session lifetime (minutes): The lifetime of Azure AD B2C's session cookie stored on the user's browser upon successful authentication.
  • Default = 1440 minutes.
  • Minimum (inclusive) = 15 minutes.
  • Maximum (inclusive) = 1440 minutes.
• Web app session timeout: If this switch is set to Absolute, the user is forced to re-authenticate after the time period specified by Web app session lifetime (minutes) elapses. If this switch is set to Rolling (the default setting), the user remains signed in as long as the user is continually active in your web application.

These are a couple of use cases that you can enable using these properties:

• Meet your industry's security and compliance requirements by setting the appropriate web application session lifetimes.
• Force re-authentication after a set time period during a user's interaction with a high-security part of your web application.

Single sign-on (SSO) configuration

If you have multiple applications and policies in your B2C tenant, you can manage user interactions across them using the Single sign-on configuration property. You can set the property to one of the following settings:

• Tenant: This is the default setting. Using this setting allows multiple applications and policies in your B2C tenant to share the same user session. For example, once a user signs into an application, Contoso Shopping, he or she can also seamlessly sign into another one, Contoso Pharmacy, upon accessing it.
• Application: This allows you to maintain a user session exclusively for an application, independent of other applications. For example, if you want the user to sign in to Contoso Pharmacy (with the same credentials), even if he or she is already signed into Contoso Shopping, another application on the same B2C tenant.
• Policy: This allows you to maintain a user session exclusively for a policy, independent of the applications using it. For example, if the user has already signed in and completed a multi factor authentication (MFA) step, he or she can be given access to higher-security parts of multiple applications as long as the session tied to the policy doesn't expire.
• Disabled: This forces the user to run through the entire user journey on every execution of the policy. For example, this will allow multiple users to sign up to your application (in a shared desktop scenario), even while a single user remains signed in during the whole time.

Introduction

Microsoft Azure is a cloud computing service. Customers can use Azure to build, test, distribute, and manage applications online. Among the several hundred features offered as part of Azure is a Single Sign On utility, accessed through Windows Active Directory. Datalogics is pleased to support Microsoft Azure as a Single Sign-On provider for READynamic.

Active Directory is a Microsoft utility that manages credentials and permissions for a network. When a user logs on to a network, Active Directory confirms that the user’s account name and password is valid. Azure extends Active Directory to include the ability to provide users with the ability to access all of the applications and services within a Windows network with single account name and password.
Azure users create tenants to organize features and services for their users. It is possible to create more than one tenant in Azure to structure your environment, each with its own set of services and applications. For example, if you represent a publishing firm, you can create separate tenants in Azure for your fiction and non-fiction publishing systems. Or you can set up a separate Azure tenant to serve systems and users in your educational publishing division, a second tenant for your retail division, and a third for your business publishing division.

You may have in place an account with Azure, and your own tenant or tenants. In fact, you may already be using Azure to provide Single Sign-On services to your users, and so you might already have a set of Azure applications that you set up to allow your users to log on to other systems. In this event, setting up READynamic to work with Azure as a Single Sign-On provider should be easy if you already have an Azure account in place.

We take you through the steps involved so that it will also be easy if you are new to Azure.

NOTE: Sometimes, when a Mac user working with the Chrome browser logs on to READynamic using the Azure Single Sign-On client, that user is sent back to the same login screen instead of to the READynamic Portal.

This rarely happens, and is easy to correct. The user should simply refresh the browser window and the appropriate screen should appear.

Setting up Your Azure Environment

1. To configure OAuth2 to work with Azure, start by visiting the Azure developer’s site, and create an account there:

2. Log on to your Azure account.

When you log on, you will see the Dashboard Screen.

If you already have a tenant in place that you can use with Azure, go to Creating a READynamic Application in Azure.

Creating a Tenant

1. If you need to create a new tenant, click:

2. Enter Azure AD B2C in the search field on the top of the screen:

3. Select Azure AD B2C:

4. Click . Click the option shown below:

5. Complete the entry screen that appears.

6. Complete the fields and click .

Creating a READynamic Application in Azure

1. From the Dashboard, click to open the All Services Screen.
2. Select “Azure AD B2C.” Azure AD B2C refers to Azure Active Directory Business to Consumer.

Take care not to confuse Azure AD B2C with Azure Active Directory. Those are in fact two completely different services; to use Azure with Single Sign-On, you need Azure AD B2C.

3. Scroll down on the All Services Screen to the section called “Identity,” or in the Filter box on the top of the screen, type in “Azure AD B2C” to search for this service.

4. Make Azure AD B2C a favorite. Click the star , so that it changes color, . If you make this service a favorite, a new tab appears on the screen on the left side of the screen, at the bottom of the tool bar:

5. Click Azure AD B2C. The Azure AD B2C window opens.

Building the Application

1. Click.

A blank Applications Screen appears.

2. Click to create a new application.

The New Application Window appears.

3. Enter the name of the application.
4. Click Yes for Web App, and enter a Reply URL.

When you create the application, enter a valid URL for the return address. After a user attempts to log on to READynamic using Azure Single Sign-On, Azure will send an authentication response to the Reply URL. This response will either be a token showing that the user is permitted to log on, or an error message. Azure directs the client to this web address for log on requests to READynamic.

Commonly, for READynamic the Reply URL is based on the URL for your customer portal. Your portal might look something like this:

https://boxcollege.readynamic.com

For use with Azure, you need to add an Azure callback statement to the end of this web address.

/auth/azure_active_directory_b2c/callback

With this syntax:

https://<portal address>/auth/azure_active_directory_b2c/callback

So the Reply URL should look something like this:

https://boxcollege.readynamic.com/auth/azure_active_directory_b2c/callback

You will need to add this value as a setting in the configuration file, omniauth_overrides.yml.

Make sure that this web address is formatted properly. It must start with 'https://'

5. When you enter a valid address, the Create button is activated. Note that you cannot create an application in your Azure account if the Reply URL is not valid.

6. Click .

You will see a message that the application was successfully created.

The new application appears on the Applications screen.

7. Click the name of the application. The Properties window appears.

Working with the Application Key in Azure

1. Next, you need to generate a key. Click :

2. Click .

3. Click . A message appears stating that the application was updated. The key appears on the Key Screen.

Applying the Key

Note that Azure generates this key as a random string of 24 alphanumeric and special characters.

It should look something like this:

Qu*j6TE09)7-QbK3p=zEk4r

You need to copy this key into a configuration file provided with the READynamic software distribution package. The software reads the key from that file parameter.

But some kinds of characters can cause problems when READynamic interprets the key value. Consider this example:

f!'3zCvxv9&ux2p^5qa3B26~

Note the double quotes character:

f!'3zCvxv9&ux2p^5qa3B26~

In text streams many applications interpret a quotation mark, single or double, as the beginning or end of a literal value. If READynamic finds a quote character in a key, it will look for a second quote character to match and will end up rejecting the key if it can’t find it. If in fact a second quote appears, READynamic will only read the characters within the quotes, not the entire key.

Likewise, if a greater than or less than symbol appears ('>' or '<') READynamic will interpret this as the beginning or end of an HTML tag marker, like '<p>' or '</b>.' The system will look for a pair of HTML elements and reject the key as undecipherable.

If Azure generates a key for your application and it includes any of these random characters, READynamic will not be able to read it, and your Azure Single Sign-On configuration will not work:

This issue is very easy to fix. Simply generate new keys for an application in Azure until you find one without any of these characters. Then, apply that key to READynamic.

Click, and then click .

Up to two keys will appear on Application Keys Screen at a time. If a key has one of these excluded characters right click on the value and click Delete to delete it. It only takes a few seconds to create or delete a key, so you should be able to quickly find one that you can use.

Adding a Policy

B2c Single Sign-on Configuration

Next, create a policy for the application. The policy describes what the user needs to provide to access READynamic through Azure, and what READynamic is looking for from a user who signs in.

1. Return to the Applications screen.

2. Under POLICIES on the left side of the screen, click .
3. Click to create a new policy.

4. Enter a name for the policy. For our example we use 'readynamic.'
5. Complete the rest of the screen and click .
6. Return to the Applications Screen.

Adding a Scope

1. From the Applications Screen, select the application.
2. Click .

3. Complete the blank fields that appear on this screen to add a new scope. Enter 'read' for SCOPE and 'any' for DESCRIPTION. When you click Save the full scope value fills in automatically. Your scope will appear in the Full Scope Value field. You will need to copy this scope value to the omniautgh_overrides.yml configuration file. We describe this below.
4. Click .
5. Click to add an API access to your scope.

6. For the Select API field, click the arrow and select your application.
7. For the Select Scopes field, select all scopes.
8. Click OK.

Configuring READynamic to work with your Azure application

At this point, you have everything you need to link your READynamic environment to Azure Single Sign-On. In creating the Application in Azure, Azure generated four values that you need to copy into a pair of YML configuration files that we provide with your READynamic software installation package. All of these values appear on the Azure Application Page.

Click Properties:

This screen provides:

A) Application ID
B) Reply URL
C) Tenant ID

Disregard the reference to the App ID URI. The tenant ID value is underlined on the above screen.

Then, click the Keys tab to display the key value:

This is an example of the policy name value:

And this screen shows the name of the scope:

For each of these four values, right click on the value to select it, and then copy and paste it into the configuration file called omniauth_overrides.YML.

omniauth_overrides.yml

You will find the Azure OAuth2 settings near the beginning of the omniauth_overrides.yml file.

When you finish editing the file, it should look something like this:

B2c Single Sign On Configuration Settings

Make sure that the web address for the redirect_uri starts with “https.”

B2c Single Sign On Configuration Yahoo Mail

server_configuration_overrides.yml

Azure B2c Single Sign On Configuration

You also need to enable Azure in the server_configuration_overrides.YML configuration file. Look for the login_strategy setting:

Set the enabled value to “true,” and add Azure as the strategy name under redirect, like this:

Save both YML configuration files and restart your READynamic server. The next time you log on, you should be asked for your Azure credentials.