AzureAD Federation Service Manual

If you are interested in using Azure AD Federation for your application please follow the
guide below to set it up. Is your application already connected to ADFS and you want to
migrate to Azure AD Federation? Please also consult this link  on top of the information
below to migrate ADFS Apps to Azure AD Federation.

Preparing your application for Azure AD Federation

Getting the required information
If the DevOps team does not have the required knowledge in-house on how the
application authenticates. please contact the application developer or vendor first to get
the required information of the topics below.

Assess what authentication protocol your application is currently using, and which
protocols your application supports. The authentication protocols which are supported
by Azure AD Single Sign-On are:

 SAML 2.0 protocol using IDPLite, SPLite & eGov1.5 profiles

 OAuth 2.0 Authorization Grant Profile
 OpenID Connect 1.0
If your application does not support one of these authentication protocols, configuring
Azure AD with Single sign-on is not possible. Other information you will need to provide
is:

 Is an application metadata URL available?

A metadata URL contains a SAML metadata document in XML format which describes a
SAML deployment to configure AzureAD as the Identity Provider. This file contains all the
required configuration information and can often be directly loaded into an application
or into AzureAD. Note that this process goes both ways, so the application can host a
metadata URL for AzureAD to automatically load the configuration, and AzureAD hosts a
metadata URL for the application to automatically load the configuration. This way, you
can prevent technical debt and configuration updates such as certificate renewals happen
automatically.
o If the application has a metadata URL available, this is the recommended
onboarding method.
o If the application does not have a metadata URL available, can the application
create a static metadata XML file? This would be the second to best option.
 Can the application handle the Azure AD metadata?
o If so, this is the recommended onboarding method.
o If not, can the application load a static metadata XML file created by Azure AD?
This would be the second to best option.
 How is user provisioning handled? It can be manual or is it automated using
Sailpoint Identity Now, Just In Time(JIT) provisioning or SCIM?
 Are all required user accounts present in the Azure Active Directory? NN’s
AzureAD contains all accounts of NN employees, contractors etc. It also contains
accounts for Tied Agents of some Insurance International countries. If other accounts are
required, they will need to be authenticated by a different Identity Provider.
 Where do you want to allow or block access from, and under what conditions?
These conditions can be based on:
(for more info on conditional access in Azure AD please consult this link 
o Group membership
o Device Platforms (Android, iOS, Windows, Mac)
o Device compliancy: Are NN policies enforced on the device, i.e. NN laptop, NN
Intune Company Portal managed laptop or smartphone, or all devices
o Sign-in risk

If you are NOT using Metadata, the following information is required

o Attributes in claim:

o What claims, claim types, and claims format should be sent? In a SAML claim,
attributes can be specified, this looks like this in a SAML response:

o <AttributeStatement>

o <Attribute Name="CorporateID">

o <AttributeValue>XY80EU</AttributeValue>

o </Attribute>

o </AttributeStatement>

The application expects specific attributes in the SAML response from AzureAD. In the
example above, the application expects the attribute named “CorporateID”. In the
example, AzureAD is configured to get the “Name” attribute from Azure Active Directory
and map it to the “CorporateID” attribute in the SAML response. Possibly, your
application expects more and/or different attributes in the attribute mapping. For
AzureAD to work, the required attribute mapping is also something you need to
configure this yourself in Azure AD.

o Identifier (Entity ID)

o SAML request signing availible?

o Token encryption availible? If yes, certificate need to be sent too

o Consumer (token) endpoint URL

 o POST back to which URL

o Supported Secure hash algorithms

* Note that we only use the Azure AD production environment. Therefore, DTA
environments are also connected to the Azure AD Production environment.

Getting a service principal in Azure AD

Find the "Enterprise Application registration" orderable item (standard change for now) in
the Service Now Catalogue. Provide at least the desired name of the application, and the
CSA account that needs to be to owner of the application. If you do not yet have a CSA
account, request it from your local AD team.

Using the Azure portal to configure your Azure AD

Federation
Good news, once you have your own service principal, you can use the Azure Portal to
set-up the Azure AD Federation yourself! Please login with your CSA account
to https://portal.azure.com , make sure that your browser doesn't log you in with your
regular corporate key account. You can do this by starting Edge InPrivate or Mozilla
Firefox, then the browser will prompt you for credentials.

In the Azure Portal, navigate to Azure Active Directory --> Enterprise Applications -->
Search for the application name (Service Principal name) you requested. Since you are
made owner of this application, you can configure everything as you would like, even
adding other owners. If you click on the "Single sign-on" tab, you are able to configure
the Azure AD Federation. Some important attributes are:

 Identifier (Entity ID): This unique identifier is used to make the connection
between the application and Azure AD. This should be identical on the Azure AD side and
on the application side
 Reply URL (Assertion Consumer Service URL): After a login attempt, Azure AD will
post the SAML response to this URL. The application should host this URL and be able to
process the SAML response sent by Azure AD.
 User Attributes and Claims: These are user specific attributes (like name, surname
or emailaddress) from Azure AD which can sent to the application during the login
attempt. Important here is that the User Identifier or "Name Identifier" is configured
identically on both sides. Within NN, a commonly used User Identifier is the coroporate
key. You can send this attribute by selecting the ExtractMailPrefix() transformation and
applying it to the user.userprincipalname attribute.

Adding device information to the SAML claim

What we do like to point out, is that it is also possible to add device information to claim
that your application will receive. This way, the application can allow or block access to
specific resources based on the device type that you're using. For example, Azure AD
distinguishes between "Known devices", "Managed devices" and "Compliant devices".
This service is currently in Preview in Azure AD, and therefore has to be added manually
to the manifest of the application registration. In the Azure Portal, go to Application
Registrations > your application > Manifest > Replace the "optionalClaims" attribute with
the following JSON:

"optionalClaims": {

"idToken": [],

"accessToken": [],

"saml2Token": [

"name": "is_device_managed",

"source": null,

"essential": true,

"additionalProperties": []

},

"name": "is_device_compliant",

"source": null,

"essential": true,

"additionalProperties": []

},

"name": "is_device_known",

"source": null,

"essential": true,

"additionalProperties": []

},

This will add device information to the SAML response during authentication. This looks
like this:
<Attribute
Name="http://schemas.microsoft.com/2012/01/devicecontext/claims/ismanaged">

<AttributeValue>true</AttributeValue>

</Attribute>

<Attribute
Name="http://schemas.microsoft.com/2014/02/devicecontext/claims/isknown">

<AttributeValue>true</AttributeValue>

</Attribute>

Please note that adding device information to the SAML claim is currently in Preview in
Azure AD. This means that Microsoft cannot give any guarantees on the stability and
availability of this service. It is strongly discouraged to use this feature in Production.

Adding group membership information to the SAML claim

Another commonly used user attribute in SAML claims is the groups attribute. You can
add this to your application via the Azure Portal > Enterprise Applications > your
application > Single Sign-on > User Attributes & Claims > Groups Returned in Claim >
Security Groups. This will add all directly and indirectly nested security groups of the user
to the SAML claim. Note that there is a hard limit of the amount of groups that can be
added to the claim, 150 for SAML assertions and 200 for JWT. If this limit is exceeded,
then a link to the Azure AD Graph API is sent instead, the full list of Security Groups can
be retrieved there. Note that the high usage of security groups within NN causes this
limit to be reached very easily. If you application is unable to handle an external API call
to retrieve the security groups from the Azure AD Graph API, please consider using
Application Roles instead.

For more information on using Application Roles, please see the Microsoft

Documentation  on Application Roles. For more information on configuring group claims
with Azure AD Federation, please see the Microsoft Documentation  on that as well.

Please note that adding group membership information to the SAML claim is currently in
Public Preview in Azure AD. This means that Microsoft cannot give any guarantees on the
stability and availability of this service. It is strongly discouraged to use this feature in
Production.

We will not go into the SAML configuration any further, because the explanations in the
Azure Portal are very clear. If you need more instructions for the configuration, please
read the "Getting Started" and the "Deployment Plan" pages in the Azure Portal.

What you need to configure on the application side

An Azure AD Federation requires configuration on the application side as well as on the
Azure AD side. If you are using a metadata URL, then configuring the URL is all you need
to do. If you manually load the metadata XML file into your application, then that is also
all you need to do (this XML can be downloaded from Azure AD if you go to your
enterprise application --> Single Sign-on tab). Otherwise you will need to manually
configure the above configuration information.

We cannot explain your application configuration more thouroughly, since the exact
configuration differs per application. In the Azure Portal you can generate all the
instructions and configuration information you need. Just go to your enterprise
application --> Single Sign-on tab --> bottom of the page click on the "Configure
<application_name>" blade. Here, all information is presented that you will need to use
to manually configure your application.

Important note: If your application authenticates against the AzureAD OpenID

Connect(OAuth) endpoint, the application must be able to initiate a outbound 443
connection to the authentication, token verification and certificate url. All these urls have
the following pattern: https://login.microsoftonline.com/* 
Because this is an external connection from the application towards AzureAD an
application RCEC is required.

Configuring Azure MFA

When the Azure AD Federation is set-up and your users can login to the application, then
you can also configure Azure MFA for your application. Note that for all SaaS applications
used withing NN, configuring Azure MFA as a login method is mandatory. Also, for
applications with a C2 (confidentiality) or I2 (integrity) rating or higher, configuring Azure
MFA is also required. This is not only required for specific cases of logins, such us specific
IP Ranges or access from outside the corporate network, but it is required for Azure MFA
to be enforced for every login in any case. This is the current NN Policy and can be found
in the Information Security Standards  in our Policy House.

By default, federating your application with Azure AD will already enforce Azure MFA
when the application is accessed from outside the NN corporate network. Note that this
does yet meet the security requirements of NN policy. To be in compliance, you will need
to explicitly enforce Azure MFA on your application within Azure AD, this is done with a
so called Conditional Access Policy.

Requesting a Conditional Access Policy

To request a Conditional Access Policy in Azure AD for your application, find the "Azure
Conditional Access or MFA on Enterprise Application Registration" orderable item
(standard change for now) in the Service Now Catalogue and specify the below
information in an ServiceNow request. If you agree with all the advised options below,
you can also indicate in your request that you want a default implementation of Azure
MFA on your application, and we will implement the Conditional Access Policy based on
the advised settings below. This will simply enforce Azure MFA for all app users. If you
have any service accounts (NPA's) which are used for automation or scripting, please
send them in the request so we can exclude them from the Conditional Access Policy.
Conditional Access Policy
Our advise
Specification

This is the Display Name of your service

Application Name
principal in Azure AD

Which users to include in

the Conditional Access All users
Policy

Do not exclude any users. Only service

Which users to exclude in
accounts (some specific NPA's) which
the Conditional Access
are used for automation or scripting and
Policy
which shouldn't have MFA enforced

Which Device Platforms to

include in the Conditial All device platforms
Access Policy

Which Device Platforms to

exclude in the Conditial Do not exclude Device Platforms
Access Policy

Which Locations (IP Ranges) Do not configure locations, because IP

to include in the Ranges of NN are not reliable since the
Conditional Access Policy implementation of Zscaler

Which Locations (IP Ranges) Do not configure locations, because IP

to exclude in the Ranges of NN are not reliable since the
Conditional Access Policy implementation of Zscaler

Which client apps (Browser

access or mobile Apps and
Do not configure and include all client
desktop clients) to include
apps
in the Conditional Access
Policy
 Conditional Access Policy
Our advise
Specification

Which device states (Azure

AD joined device or
compliant devices) to Do not configure and include all devices
exclude from the
conditional access policy

Which additional
requirements (Azure MFA,
Azure AD joined device
Require Azure MFA
and/or compliant device) to
grant access to the
aplication

Comparison with between Azure AD Federation and ADFS

All new application federation requests will be federated with Azure AD, since that is the
new standard. Currently there are two exceptions where ADFS could still be required for
your application federation:

 If complex claim rule transformations are required. The claim rule transformation
options in Azure AD are currently limited. Please check with the team first, as they may be
able to help you create the correct claim rule transforms in AzureAD.
 If the application requires request signing. Note that signing of the SAML
assertion and of the SAML response is supported in Azure AD. Same goes for token
encryption, but request signing is not yet possible with Azure AD Federation.
Please note that onboarding in ADFS is only done when the ADIDAS team has concluded
the application cannot be onboarded in AzureAD Federation.