When a user authenticates to an application, a custom claims provider can be used to add claims into the token.
A custom claims provider is made up of a custom authentication extension that calls an external REST API to
fetch claims from external systems. In this demo shows how you can add custom claims from Woodgrove REST API into security tokens.
Including the loyaltyNumber, loyaltySince, and loyaltyTier claims.
These claims return by a custom authentication extension REST API with some random values.
To add a custom authentication extension, sign in to the Microsoft Entra admin center
and browse to External Identities > Custom authentication extensions .
Note, you can also browse to Applications > Enterprise applications > Custom
authentication extensions .
From the Custom authentication extensions page, select Create a custom extension.
In Basics, select the TokenIssuanceStart event type and select Next.
In Endpoint Configuration, fill in the following properties:
Name - A name for your custom authentication extension. For example,
Add claims from customer relationship REST API.
Target URL - The URL of your REST API.
Timeout in milliseconds - The maximum number of retries the API endpoint will be
called
in case of failure. If empty, will default to service default.
Maximum Retries - The maximum number of retries the API endpoint will be called in
case
of failure. If empty, will default to service default..
Description - A description for your custom authentication extensions.
To continue, select Next.
To ensure the communications between the custom authentication extension and your REST API are
secured appropriately, multiple security controls must be applied. The first step is to create
or
choose
an application that Microsoft Entra ID uses the OAuth 2.0 client credentials grant flow to
secure
the
call to your API endpoint.
If this is your first custom authentication extension (if not, scroll down), in API
Authentication, select the
Create new app registration option to create an app registration
that represents your REST API.
Give the app a name, for example Custom authentication extension security app and
select Next.
If you have already configured a custom authentication extension, in API Authentication,
select
the
Select an existing app registration in this directory option, and select the application
you
configured for the other custom authentication extensions.
In Claims, enter the attributes that you expect your custom authentication extension to
parse
from
your REST API and will be merged into the token. Then, to continue select Next.
Review your configuration and select Create, which registers the custom authentication
extension and the associated application registration
you selected or choose to create.
If earlier you choose the Create new app registration option, after your custom
authentication
extension is created, you need to grant permissions to the API.
Open the Overview page of your new custom authentication extension. Under API
Authentication, select Grant permission.
A new window opens, and once signed in, it requests permissions to receive custom authentication
extension HTTP requests. This allows the custom authentication extension to authenticate to your
API. Select Accept.
Take a note of the App ID under
API Authentication, as it will be needed when you configure your REST API access token
validation.
At this point your custom authentication extension is configured but is not associated with any
application.
In the next few steps you will configure your application to add the attributes
returned from the custom authentication extension mapped into the security tokens.
From the menu, select App registrations and select your application. In this example we
select the Woodgrove Groceries
application.
In your application registration, under Manage, select Manifest.
A web-based manifest editor opens, allowing you to edit
the manifest.
In the manifest, locate the acceptMappedClaims attribute, and set the value to
true.
Set the accessTokenAcceptedVersion to 2.
Select Save to save the changes.
To assign the custom authentication extension as a custom claims provider source, from the
app Overview page, select the link next to Managed application in local directory.
Note, you can also browse to Enterprise applications, then under Manage, select
All
applications, and then select your application from the list.
From the menue, select Single sign-on. Then, under Attributes & Claims, select
Edit.
Expand the Advanced settings menu. Next to Custom claims provider, select
Configure.
Expand the Custom claims provider drop-down box, and select the Token issuance event you
created
earlier. Select Save to save the changes.
Next, assign the attributes from the custom claims provider, which should be issued into the
token
as claims:
Select Add new claim to add a new claim.
Provide a name to the claim you want to be issued, for example loyaltyNumber.
Under Source, select Attribute, and choose customClaimsProvider.loyaltyNumber from
the
Source
attribute drop-down box. Note, the name can be differed from the source. For example, the
name can be
CustomerNumber, while the source must be one from the list.
Well done!
Your custom authentication extension is
configured, and
claims that it returns will be included in the access token for your application.
To register a web application, use the following
Microsoft
Graph. The name of the application will be Custom authentication extension security app.
POST https://graph.microsoft.com/v1.0/applications
{
"displayName": "Custom authentication extension security app",
"description": "Ensure the communications between the custom authentication extension and your REST API are secured",
"signInAudience": "AzureADMyOrg",
"tags": [
"HideApp"
],
"api": {
"acceptMappedClaims": null,
"requestedAccessTokenVersion": 2
},
"requiredResourceAccess": [
{
"resourceAppId": "00000003-0000-0000-c000-000000000000",
"resourceAccess": [
{
"id": "214e810f-fda8-4fd7-a475-29461495eb00",
"type": "Role"
}
]
}
]
}
1.1 Copy the application ID
From the response, copy the value of the appId. For example:
{
"@odata.context": "https://graph.microsoft.com/v1.0/$metadata#applications/$entity",
"id": "12345678-0000-0000-0000-000000000000",
"appId": "22222222-0000-0000-0000-000000000000",
"displayName": "Custom authentication extension security app",
"description": "Ensure the communications between the custom authentication extension and your REST API are secured",
...
}
1.2 Update the application identifier URI
After you register you registered your application, Update the application's' identifier URI.
Replace the {app-ID} with the app ID from the previous call (not the object ID).
Replace the {REST-API-domain} with your rest API domain name.
1.3 Create a service principal for your application
After you register you registered your application, create a service principal. The following Microsoft
Graph creates a service principal. Replace the {app-ID} with the app ID from the previous call
(not the
object ID).
POST https://graph.microsoft.com/v1.0/servicePrincipals
From the response, copy the value of the id. For example:
{
"@odata.context": "https://graph.microsoft.com/v1.0/$metadata#servicePrincipals/$entity",
"id": "77777777-0000-0000-0000-000000000000",
"appDisplayName": "Custom authentication extension security app",
"appDescription": "Ensure the communications between the custom authentication extension and your REST API are secured",
"appId": "12345678-1234-1234-1234-000000000000",
}
1.5 Get the Microsoft Graph's service principal ID
Run the following GET request and cope the id from the response:
GET https://graph.microsoft.com/v1.0/servicePrincipals(appId='00000003-0000-0000-c000-000000000000')
Since the tenant is a customer's tenant, the consumer users themselves can't consent to these permissions.
You as the admin must consent to these permissions on behalf of all the
users in the tenant:
Replace the {service-principal-id} with the service-principal ID you created in the previous step.
Replace the {graph-service-principal-id} with the service-principal id you copied in the last
step.
Note, in the following JSON snippet, the 214e810f-fda8-4fd7-a475-29461495eb00 ID is the
CustomAuthenticationExtension.Receive.Payload application role.
POST https://graph.microsoft.com/v1.0/servicePrincipals/{service-principal-id}/appRoleAssignments
Next, you register the custom authentication extension.
You register the custom authentication extension by
associating it with the Custom authentication extension security app you created, and to your
REST API endpoint. Replace:
{app-ID} with the app ID from the previous call Custom authentication extension security
app.
{REST-API-domain}with your rest API domain name
{Endpoint-URL} - with the RUL of your REST API endpoint
claimsForTokenConfiguration - Collection of attribute your REST API returns
POST https://graph.microsoft.com/beta/identity/customAuthenticationExtensions
From the response, copy the value of the id. For example:
{
"@odata.context": "https://graph.microsoft.com/beta/$metadata#identity/customAuthenticationExtensions/$entity",
"@odata.type": "#microsoft.graph.onTokenIssuanceStartCustomExtension",
"id": "22222222-2222-3333-3333-444444444444",
"displayName": " Add claims from customer relationship REST API",
"description": "Returns the loyaltyNumber, loyaltySince, and loyaltyTier claims with some random values",
}
{web-or-mobile-app-ID} with your web or mobile application. Not the Custom authentication
extension security
app. It's a collection, you can add more apps as needed.
{Custom-auth-extension-ID} with the custom authentication extension you just created.
POST https://graph.microsoft.com/beta/identity/authenticationEventListeners
Configure your web or mobile application metadata's acceptMappedClaims attribute to true.
Also, the accessTokenAcceptedVersion to 2.
Replace the {app-ID} with your web or mobile application. If you have more than one application,
repeat this step.
Microsoft Entra External ID offers solutions that let you quickly add
intuitive, user-friendly sign-up and sign-up experiences for your customer apps.
The Woodgrove Groceries live demo illustrates several of the most common
authentication experiences that can be configured for your consumer-facing apps.
From the above dropdown list, select a use-case and start the
demo.
Watch this video to learn more about the Woodgrove live demo.
Online retail demo
The online retail use case is an end-to-end demonstration that illustrates
several of the most common authentication
experiences that can be configured for your customer-facing apps.
To run the use case, follow these steps:
Select the start the use case button at the bottom of this page.
From the sign-in page select No account? Create one.
Enter your email address, which will be verified and becomes your login ID.
Open your mailbox and copy the verification code sent to you. Then, on the sign-in
page enter the verification code and select next.
After the email was verified, enter a password, and re-enter the password,
and enter your account details.
You can create a custom look and feel for users signing in to your apps.
With these settings, you can add your own background images, colors, company logos, and text to
customize the sign-in experiences across your apps.
So that the sign-in page blends seamlessly into woodgrove applications’ look and feel.
For more information, learn how
to customize the neutral branding in your customer tenant.
Select the start the use case button at the bottom of this page.
On the sign-in page take a look on the header, the header logo, the banner logo, the title,
buttons, and the background image which are all customized.
The sign-in text appears with some guidance for the users
The footer contains links to the term of use and privacy policies. Both the links and the text
can be customized
The custom
URL domain provides a more seamless user experience. From the user's perspective, they
remain
in
your domain during
the sign in process rather than redirecting to the Microsoft Entra external ID default domain
{tenant-name}.ciamlogin.com. Note, this feature is currently in private preview and also
limited
to sign-in with local accounts.
Social accounts such as Google or Facebook are not yet supported.
Select the start the use case button at the bottom of this page.
Take a look on the URL in the web browser address bar. It should be
login.woodgrovedemo.com
You can sign-up or sign-in with local account. Do NOT use the Facebook or Google options.
The custom
email allows you to send customized emails to users who sign up, reset their password,
sign-in with email and one-time passcode, or email multifactor authentication (MFA).
Select the start the use case button at the bottom of this page.
From the sign-in page select No account? Create one.
Enter your email address, which will be verified and becomes your login ID.
Check your mailbox and review the email. Pay attention to the sender, the subject line, and the
content of the email, they are all customized to align with Woodgrove's branding.
You can create a personalized sign-in experience for users who sign in using a specific browser
language by customizing the branding elements for that browser language. This customization
overrides any configurations made to the default branding.
For more information, learn how
to customize the language of the authentication experience.
Make sure your browser is configure to any language other than German
Select the start the use case button at the bottom of this page.
Duing the sign-up or sign-in flow, the user's language is dictated by their browser's settings.
Application can pass the ui_locales and mkt parameters with a specific language.
Self-service password reset (SSPR) gives users the ability to change or reset their
password, with no administrator or help desk involvement. If a user's account is locked
or they forget their password, they can follow prompts to unblock themselves and get
back to work. For more information, learn
how to enable self-service password reset.
Users can sign in with their existing social accounts, without having to create a
new account. For more information, learn how to add Google
and Facebook
identity providers.
Select the start the use case button at the bottom of this page.
From the sign-in page, select Google. Then you will be redirected to Google
sign-in page.
If asked, consent to grant the permissions that Microsoft Entra external ID is requesting.
Upon first sign-in, complete the registration by entering your account details.
Sign-in with Microsoft personal account (live.com)
Users can sign in with their existing Microsoft personal account accounts (live.com), without having to create a
new account. For more information, learn how to Set up your OpenID Connect identity provider.
Select the start the use case button at the bottom of this page.
From the sign-in page, select Sign-in with Microsoft personal account. Then you will be redirected to live.com
sign-in page.
If asked, consent to grant the permissions that Microsoft Entra external ID is requesting.
Upon first sign-in, complete the registration by entering your account details.
During a sign-in an application may target a specific user. When targeting a user, an application
can specify, in the authorization request, the
'login_hint' query parameter with the user sign-in name. Microsoft Entra external ID automatically
populates the
sign-in name, while the user only needs to provide the password.
Enter a username:
Make sure you enter an account that exists in the directory.
Select the start the use case button at the bottom of this page.
From the sign-in page, notice that the username aleardy entered.
In an "act as" or "delegation" scenario, a signed-in user (the delegate) acts on behalf of
another user
(the principal). For instance, in a corporate context, an executive assistant
(the agent) may need to approve expenses on behalf of the chief financial officer (the principal).
Another example is helpdesk personnel (the agent) performing actions on behalf of a customer (the
principal).
In these cases, the agent is provided with a security token that permits them to act as the
principal. To obtain this token, the principal must first approve it. Upon receiving
approval, the
agent may request a new security token that includes the act_as claim with the value
specifying
the name or ID of the principal (the chief financial officer or customer).
The application uses the act_as claim to operate on behalf of the principal. To start the
demo:
Select the start the use case button at the bottom of this page.
Sign-up or sign-in with your email, or a social account.
Email with one-time passcode is an option in your local account identity provider
settings.
With this option, the customer signs in with a temporary passcode instead of a stored
password
each time they sign in.
Create a new Woodgrove account
Select the start the use case button at the bottom of this page.
From the sign-in page select No account? Create one.
Enter your email address, which will be verified and becomes your login ID.
Open your mailbox and copy the verification code sent to you. Then, on the sign-in
page enter the verification code and select next.
After the email was verified, enter your account details.
Select next to complete the registration.
Sign-in with your email
Select the start the use case button at the bottom of this page.
On the sign-in page, enter your email, and select next.
Open your mailbox and copy the verification code sent to you. Then, on the sign-in
page enter the verification code and select next.
Conditional Access and Multifactor authentication (MFA)
Microsoft Entra Conditional Access brings signals together, to make decisions, and enforce security
policies.
Multifactor authentication (MFA) protects customers identity by prompting
them for a second verification method. For more information,
learn
how to add MFA.
In this demo a Conditional Access policy that's targeted to all users when the sign-in risk level is
medium or high, prompts for MFA.
Select the start the use case button at the bottom of this page.
Sign-up or sign-in with your email, or a social account.
As a secdond factor authenticate, Microsoft Entra ID will send you a verification code to your
email or phone that you need to complete.
Applications registered in a Microsoft Entra tenant are, by default, available to all users of the
tenant who
authenticate successfully. You can configure your application to be restricted to a certain set of users or
apps.
In this demo only selected users (Woodgrove partners) can sign-in to the Woodgrove partners
portal. Other users
are not allowed to sign-in.
Select the start the use case button at the bottom of this page.
Sign-up or sign-in with your email, or a social account.
After you completed the sign-in, you will get an error message that you can't sign-in to the
Woodgrove partners portal
Note, in this demo you can't assing youself to the Woodgrove partners portal app. If you are
intrested in app assignment, check out the
Role based access controll demo
Microsoft Entra Conditional Access brings signals together, to make decisions, and enforce security
policies.
Multifactor authentication (MFA) protects customers identity by prompting
them for a second verification method. For more information,
learn
how to add MFA.
In this demo a Conditional Access policy that's targeted to all users when the sign-in risk level is
medium or high, prompts for MFA.
Select the start the use case button at the bottom of this page. Sign-up or sign-in with
your account.
After you signed-in, proceed to the next step.
For this demo, download and run the Tor
Browse. It's an open-source web browser that helps people use the internet anonymously.
Therefore, Microsoft Entra ID may consider your sign-in request as suspicious.
In the Tor browser Navigate to https://woodgrovedemo.com
Use the Microsoft Entra Conditional Access engine's authentication
context to trigger a demand for step-up authentication from within your application.
This demo allows customer to access the app and purchase items. However, upon risky action, for
example
When a Woodgrove customer finishes shopping and proceeds to the checkout.
If the sum of the items in the shopping cart is higher than usual it requires the customer to
sign-in with a strong factor authentication.
Select the start the use case button at the bottom of this page. Sign-in with
your account. Note, if you create a new account, you fulfill the MFA requirement since the email
is already verified. Therefore, make sure you sign-in with an existing account.
Custom security attribute based conditional access
Application filters for Conditional Access allow you to tag your application with custom
attributes. These custom attributes are then added to their Conditional Access policies. Filters for
applications are evaluated at token issuance runtime.
In this demo a conditional access block access to all applications tagged as
BlockGuestsUsers.
Select the start the use case button at the bottom of this page.
Sign-up or sign-in with your email, or a social account.
Upon successful sign-in you will get an error message that you don't have access to the app.
When users authenticate to your application with Microsoft Entra External ID, a security
token is return to your application. The security token contains claims that are
statements about the user, such as name, unique identifier, or application roles.
Beyond the default set of claims that are contained in the security token you can add
more claims.
This demo shows how to add addtinal attributes to the access and ID tokens.
Select the start the use case button at the bottom of this page.
Sign-up your email, or a social account.
After you validate your email, or sign-in with your social account, complete the
registration by providing your details.
The special diet is a custom attribute you can provide. For the demo enter,
Egg allergy This attribute will be included in the security token that return
to the Woodgrove application.
From the Woodgrove header, select your name, which will take you to the security
token page. The security token page contains the claims that return by Microsoft Entra
External ID. Look for the special diet claim
When users authenticate to your application with Microsoft Entra External ID, a security
token is return to your application. The security token contains claims that are
statements about the user, such as name, unique identifier, or application roles.
Select the start the use case button at the bottom of this page.
Sign-up or sign-in with your email, or a social account.
From the Woodgrove header, select your name, which will take you to the security
token page.
The security token page contains the claims that return by Microsoft Entra External ID.
Locate the loyaltyNumber, loyaltySince, and loyaltyTier
claims and check their value. These claims were returned by a custom authentication
extension REST API with some random values.
The on-behalf-of (OBO) flow describes the scenario of a web API using an identity other than its own
to call another downstream web API. For the middle-tier web API to make authenticated requests to
the
downstream web API it needs a different audience and another set of scopes (permissions). For more
information,
Microsoft identity platform and OAuth 2.0 On-Behalf-Of flow
This demo shows how the Account web
API makes authenticated requests to a downstream Payment web API.
To call the Payment web API, the Account web API acquires an access
token for the Payment web API (audience or aud claim) and another set of scopes (permissions) that
require by the Payment web API.
Select the start the use case button at the bottom of this page.
Sign-up or sign-in with your email, or a social account.
After you sign-in you will be redirected to the token page. You can also select your name
from the header.
Then, select the Access token to call a web API button.
It shows you two links to the https://jwt.ms app with the corresponding access tokens. The first
access
token is the one returned to the Woodgrove demo application and used to call the first web API
(Account).
The second one shows the access token the Account web API acquires to call the Payment web
API.
Compare the access tokens to understand the on-behalf-of flow.
The custom authentication extension supports the on
attribute collection start event. This
event occurs at the beginning of the attribute collection step, before the attribute collection page
renders.
You can add actions such as prefilling values and displaying a blocking error.
This demo shows how to prepopulate some of the values, including pre selecting the country attribute
with spain and generating and set the value of the promo code attribute.
To start the demo:
Select the start the use case button at the bottom of this page.
After you validate your email, or sign-in first time with your social account, you will be taken
to the sign-up page.
On the sign-up page notice that the Spain country was selected for you. Also at the
bottom of
the page you can see that the promo code was generated and entered for you. Both values
were provided by a custom authentication extension.
The custom authentication extension supports the on
attribute collection submit event. This
event allows you to
perform validation on attributes collected from the user during sign-up.
This demo validates the
city name against a list of cities and countries compiled in the Woodgrove custom authentication
extension REST API.
Select the start the use case button at the bottom of this page.
Sign-up with your email, or a social account. If you already have an account,
delete it.
After you validate your email, or sign-in with your social account, complete the
registration by providing your details.
For the country, leave the Spain selected, and then for the city Berlin (Berlin is
not a city in Spain).
Select next to create a Woodgrove online identity. And you should get an
error message that Woodgrove doesn’t operate in this city. Because Berlin is a city in Germany,
not in Spain.
Corrects the city name. For example, enter Madrid and try to complete the
registration again.
The custom authentication extension supports the on
attribute collection submit event. These event allows you to
modify and override attributes provided by the user.
This example shows how to modify the display name and the name of the city.
Select the start the use case button at the bottom of this page.
Sign-up with your email, or a social account. If you already have an account,
delete it.
After you validate your email, or sign-in with your social account, enter a display name
in upper case. For example, DAVID
For the city attribute, enter modify.
Select next to try to create a Woodgrove online identity. At this time the custom
authentication extension
will capitalize the dispaly name (only first leter in upper case). The city will be
modified
to Madrid.
Select your name from the header, it shows the content of the access token.
The custom authentication extension supports the on
attribute collection submit event. These event allows you to
block the user from continuing the sign-up process.
For example, you could use an identity verification service or external identity data source to
verify the user's email address.
This demo validates uses the on attribute collection submit even to check the
value
of the city attribute and block the process.
Select the start the use case button at the bottom of this page.
Sign-up with your email, or a social account. If you already have an account,
delete it.
After you validate your email, or sign-in with your social account, complete the
registration by providing your details.
For the city attribute, enter block.
Select next to try to create a Woodgrove online identity. At this time the sign-up
process will be canceled all together.
This is because the custom authentication extension checks the city value. If it contains
block, it returns the show block page action.
Arkose Labs' New Account Fraud Solution is designed to combat the creation of fraudulent accounts to ensure the security of your application while maintaining a seamless onboarding experience for legitimate users.
After a user has entered their profile data and the account is ready to be created, an additional page will appear presenting an interactive CAPTCHA-style puzzle. These puzzles are designed to be easily solvable by humans yet challenging for “bots” or scripts.
The Arkose solution is integrated within Microsoft Entra external ID (private preview) and offers organizations seamless deployment, and tools to combat fake account creation effectively.
Select the start the use case button at the bottom of this page.
Sign-up with your email. If you already have an account,
delete it.
After you validate your email, complete the
registration by providing your details.
Select next to try to create a Woodgrove online identity.
Role-based
access control is a popular mechanism to enforce authorization in
applications. It helps you manage who has access to your application and what they can
do in the application. In this demo, you assign yourself to application roles which are
automatically
approved.
To start the demo:
Select the start the use case button at the bottom of this page.
Sign-up or sign-in with your email, or a social account.
From the Woodgrove header, select the profile button.
In profile page add yourself the Products.Contributor and Orders.Manager roles.
To reflect the changes in the security token, sign-in again with the same account (you won't be
asked to enter the credentials).
After you sign-in, the Manage products and Orders buttons appear in the header.
Select your name from the header to show the security token.
It should contain the role claims you assigned to.
Group-based
access control
is a popular mechanism to enforce authorization in
applications. It helps you manage who has access to your application and what they can
do in the application. You can also alter the UI based on the user's membership.
In this demo, you add yourself to the Commercial Accounts security group and you will get
a discount for some of the products.
To start the demo:
Select the start the use case button at the bottom of this page.
Sign-up or sign-in with your email, or a social account.
From the Woodgrove header, select the profile button.
In profile page, add yourself to
the Commercial Accounts security group and update your account.
To reflect the changes in the security token, sign-in again
with the same account (you won't be asked to enter the credentials).
Now that you are a member of the Commercial Accounts security group, you get a discount to some
of
the products.
Note, if you select your name from the header, it shows the content of the access token
issued by Microsoft Entra External ID that was returned to the application.
It should contain the groups claims.
This demo application checks the claim’s value and gives you the discounts.
Collect user attributes during sign-up
User attributes are values collected from the user during self-service sign-up.
In the user flow settings, you can select from a set of built-in user attributes you
want to collect from customers. You can also create custom
user attributes and add them to your sign-up user flow. For more information, learn
how to collect user attributes during sign-up.
On the sign-up page the user enters the information, and it's stored with their
profile in your directory.
This demo shows the use of built-in attribute and custom attribute called special
diet. To start the demo:
Select the start the use case button at the bottom of this page.
After you validate your email, or sign-in with your social account, complete the
registration by providing your details.
The special diet is a custom attribute you can provide. For the demo enter,
Egg allergy This attribute will be included in the security token that return
to the Woodgrove application.
Select next to create a Woodgrove online identity.
After you successfully sign-in, in the home page, the Eggs product will show an
allergy warning.
Microsoft Entra external ID allows applications to start the authorization request with sign-up flow
(using the 'prompt=create' query parameter).
You can also provide an email address (using the
'login_hint' query parameter). If provided, Microsoft Entra external ID automatically
populates the
sign-up email address, while the user only needs to validate their email address and enter their
profile attributes. Make sure there is no such account in the directory.
[Optimally] Enter an email: .
Select the start the use case button at the bottom of this page.
Notice that the title of the page is "Create account"
If email has been provided, notice that the email address already entered.
Terms of use, also known as terms and conditions or terms of service, are rules, specifications, and
requirements for the use of your app.
Microsoft Entra external ID allows you to add a custom attribute (type of Boolean) to the sign-up
page.
Before completing the sign-up, users should read and accept your policies.
For more information, learn how to collect user attributes during sign-up and
configure a single-select checkbox.
This demo shows to add links to terms of use and privacy policies. To start the demo:
Select the start the use case button at the bottom of this page.
After you validate your email, or sign-in with your social account, complete the
registration by providing your details.
Select the terms of use and privacy policies links which will be opened in a new browser
tab. Then, close the tabs and go back to the sign-up page,
and select the checkbox.
Select next to create a Woodgrove online identity.
Single sign-on (SSO) adds security and convenience when users sign-in across multiple applications
in Microsoft Entra ID.
With single sign-on, users sign-in once with a single account and get access to multiple
applications.
When the user initially signs-in to an application, Microsoft Entra ID initiates a single sign-on
session.
Upon subsequent authentication requests, Microsoft Entra ID validates the session, and issues a
security token without prompting the user to sign in again.
For tests only! You can specify the lifetime of an access token, ID token, or SAML token
issued by the Microsoft
Entra ID. You can set token lifetimes for all apps in your tenant, or for service principals. You
cannot set token lifetime policies for refresh tokens and session tokens.
Select the start the use case button at the bottom of this page.
Sign-up or sign-in with your email, or a social account.
Select your name from the header to show the security token.
Scroll down to check your token expiration.
Single sign-on (SSO) adds security and convenience when users sign-in across multiple applications
in Microsoft Entra ID.
With single sign-on, users sign-in once with a single account and get access to multiple
applications.
When the user initially signs-in to an application, Microsoft Entra ID initiates a single sign-on
session.
Upon subsequent authentication requests, Microsoft Entra ID validates the session, and issues a
security token without prompting the user to sign in again.
You can force the user to enter their credentials on a sign-in request, negating single-sign on
session.
To do so, select the start the use case button at the bottom of this page.
Input-constrained devices are devices that their screen or monitor is limited to
text-only and they don't have a web browser. For example, smart TV, IoT device, robot,
gaming console, printers. Or applications with limited user interface, such as a command
line application.
These devices are connected to the internet, but due to the input constrains, the
authentication should be done on another device. The input constrained device gets a
device code from Microsoft Entra External ID and asks the user to visit a webpage in a browser
on a second
(rich device), such as smartphone, tablets, or PCs.
In this use case, from the Kiosk page select sign-in. Use the second device, such as
smartphone and scan the QR code. On the sign-in page enters the device code, and
completes the sign-in. Once you signed in, the Kiosk (input-constrained device) is able
to get security tokens and authenticate you. Your name should be presented on the
top-right corner of the page.
The Woodgrove Bank demo
application illustrates the sign-up and sign-in authentication experiences for financial scenarios.
It also demonstrates the SAML protocol federation with Microsoft Entra External ID.
The Cloudflare WAF safeguards web applications from DDoS attacks, malicious bots and more. It allows you blocking requests from specific IPs or ranges. In this example, requests from the Tor network will be blocked.
For this demo, download and run the Tor
Browse. It's an open-source web browser that helps people use the internet anonymously.
In the Tor browser, reopen this page https://woodgrovedemo.com/#usecase=CloudflareNetwork
Then, select the start the use case button (at the bottom of this page).
A Cloudflare page will display a message indicating that access from the Tor network is restricted.
The Cloudflare Web Application Firewall (WAF) non-interactive JavaScript challenge is a security feature designed to protect websites from malicious bots and other automated threats.
When a visitor's IP address shows suspicious behavior or triggers a WAF custom rule, Cloudflare presents a challenge page that requires no interaction from the visitor.
Instead, the visitor's browser processes the JavaScript challenge automatically, typically within a few second.
Select the start the use case button at the bottom of this page.
Cloudflare automatically presents challenge page that requires no interaction from you.
Wait until the browser finishes processing the challenge.
Cloudflare Web Application Firewall (WAF) offers an interactive challenge with CAPTCHA as part of its bot protection features. This type of challenge is designed to distinguish between human users and automated bots by requiring the user to complete a CAPTCHA, such as clicking a checkbox or solving a puzzle.
Select the start the use case button at the bottom of this page.
Cloudflare will present an interactive challenge that requires you to complete it, such as clicking a checkbox.
When completed, you will land on the Sign-in page.
It enables you to create visually appealing, pixel-perfect authentication screens that seamlessly blend into your app’s interface. With this approach, you can fully customize the user interface, including design elements, logo placement, and layout, ensuring a consistent and branded look
A single-page application (SPA) loads a single web page from the web server and updates the content dynamically using JavaScript.
The front end is written in JavaScript or TypeScript, often utilizing frameworks
like Angular,
React, or
Vue. The authentication flow is managed on the client side with JavaScript code.
This demo presents a SPA app that offers sign-in options using a popup window, maintaining the context of the app, and redirecting to Microsoft Entra External ID.
If you would like to delete your account and personal information, visit the delete my
account page. You won't be able to reactivate your account. In a couple of minutes you
will be able to sign-up again with the same credentials.
Disabling an account can be a critical step for businesses in managing their security and
operational efficiency. When an account is disabled, it prevents unauthorized access to your
application. This demo allows you to disable your account. Keep in mind that you will not be able to
sign-in and enabled your account. Therefore, use a temporary email for this use case.
Select the start the use case button at the bottom of this page.
Sign-up or sign-in with your email, or a social account.
After you sign-in, you will be taken to the profile page.
Uncheck the Enable checkbox and select Save.
Wait for a couple of seconds and try to sign-in again.
The user insights provides data analytics into user activity and engagement for your registered
applications within your customer tenant.
Use Microsoft Graph and the Microsoft Entra Admin Center to view, query and analyze user activity
data. For more information, learn Gain
insights into your app users’ activity.
This demo uses Microsoft Graph API to query the usage & insights (daily and monthly) to uncover valuable insights that can aid
strategic decisions and drive business growth.
Microsoft Entra ID emits sign-in logs containing activity information. Each sign-in attempt
contains
details associated with those three main components: Who: The identity (User) doing the sign-in. How: The client (Application) used for the
access. And What: The target (Resource) accessed by the identity.
You can use the sign-in logs to answer questions such as: How many users signed into a particular
application this week?
How many failed sign-in attempts occurred in the last 24 hours?
Are users signing in from specific browsers or operating systems?
Microsoft Graph PowerShell is a robust
solution for
automating tasks, executing batch
operations, maintaining and ensuring consistency across different stages such as test,
preproduction, and production
environments.
With GitHub workflow you can automate
process that will run one or
more jobs.
Their benefits in accelerating and stabilizing the deployment process to
Microsoft Entra's external ID. It leads to a significant reduction in integration
issues, faster release cycles, enhance change management, and consistency that are crucial for
maintaining data
integrity and smooth and seamless deployment during updates and modifications.
