[Azure Authentication Provider] Azure Authentication Provider - Setup and Configuration

Forge Component
(4)
Published on 15 Feb (4 days ago) by João Miguel Pereira de Figueiredo
4 votes
Published on 15 Feb (4 days ago) by João Miguel Pereira de Figueiredo

Hi All,

This component was developed internally in order to have the authentication on our environments and dev tools completely integrated with the Azure AD. 

As we understand this is something that may benefit our community of customers and partners we've decided to release a version so it may work either as a base (or if it fits your purpose as is).

A huge thanks to João Figueiredo for all the hard work around this.

Once again this component is NOT SUPPORTED BY OUTSYSTEMS.

Below you may find the configuration steps for this component to work extracted from our internal documentation

Cheers,

Guilherme

Configuration

Azure AD side

The AAP relies on Azure AD to provide authentication methods and user data.

To access Azure AD resources that we need it's imperative that we register two target apps:

- A 'native application' for user authentication that uses ADAL (let's call it AAP_USER_ADAL


- A 'web application', to provide AAP access to user's Azure AD profile (let's call it AAP_AAD_REST)


To configure AAP, we need a couple of IDs and Keys from Azure.

- At Azure AD Management Portal we need the Tenant Id.

- Regarding the AAP_USER_ADAL we need the Client Id given to this registered application.

- From AAP_AAD_REST we need the generated Client Id, and it is necessary to create a Key (also known as Client Secret) for this registered application.
  Beware, the Key (also known as Client Secret) has an expiration date.


It's recommended to read this MSDN blog entry Accessing Azure App Services using Azure AD Bearer token.


LifeTime side


Create Basic User

The AAP handles user create and update actions using the LifeTime Services API. To do so, it requires a Lifetime Basic User with User Management privileges.

Furthermore, it is necessary to define a Lifetime Role to assign to all new users that are automatically created by AAP.


AAP Installation & Configuration

Install this module in all environments managed by Lifetime.

After successful deployment of AAP module it's necessary to configure the "Consumed SOAP Web Services" (AuthenticationService, LifetimeUserManagementService and RoleManagementService) via Service Center (in all environments):


After configuring the "Consumed SOAP Web Services", it's necessary to change the authentication provider in Lifetime by following the steps in this document Use an External Authentication Provider

These are the steps required:


- Map users from the external system to the platform; (the AAP maps the users for you, as they try to access)

- Choose the new authentication method AzureAuthProvider;

- Configure the provider in the infrastructure management console (LifeTime) environment;

- Test your configuration settings and propagate them to all other environments;

- Test the provider in all environments and apply your changes.


We give focus on the third step 'Configure the provider in the infrastructure management console (LifeTime) environment'.


After choosing the Azure Authentication Provider, it’s time to configure it. You are required to provide configuration values for a single environment and then propagate those configuration values to other environments.

To start the configuration:


Click in the Configuring link. This link opens the login screen of the AAP module:

On successful login, it will redirect to the Configuration page:

Enter the required data to configure the authentication provider

After entering the necessary data, click on the Save Configuration button.

The configuration is saved and validated. On success, it's possible to read the above message.

If the validation fails,

 it's possible to read the message "These parameters were saved, but the configuration is not valid".


After having your configuration parameters validated it's time to test User Login. To do so, click on Test User Login link.

In this Screen, it's possible to test User Login With Credentials or Via SSO. 

Disclaimer: It is possible also to test the login fallback,  using a platform user's credentials currently active in Lifetime platform to login (e.g., Admin accounts).


Testing user credentials:

Inserting valid user credentials, we receive the message presented in the screenshot above.

Testing with incorrect user credentials:We receive the error message above.


Regarding SSO testing,

If we provide an existing UserPrincipalName (UPN), we receive the message presented in the screenshot above.


If we provide a not existing UPN,We receive the error message presented above.


Close the current provider configuration page, returning to the Authentication Mode page to proceed with the configuration

Click the Test in LifeTime link. This link tests if the plugin is configured correctly in the infrastructure management console environment and that it can successfully authenticate IT users.


If the test ran successfully, click the Propagate link to propagate the configuration settings to all the environments of your infrastructure.

If you get an error while propagating your changes to all environments, please check the Service Center error log regarding this module, in every affected environment.


After completing this step, you may return to the third step in this document Use an External Authentication Provider.

Important: After successfully install and apply this module in all your infrastructures, please wait for about 2 minutes, to AAP complete the bootstrap action that syncs the existing lifetime users with Azure AD's Users or, an alternative is to force the “BootStrapOnActivation” timer to run.


User Sync & Bootstrap

On completing the AAP configuration and applying it to all Lifetime managed environments, it will start a bootstrap process (timer) to sync the current Lifetime users with Azure AD ones. 

For each Lifetime user, this module will search a matching Azure AD user with the same username (SamAccountName or UserPrincipalName) or the same email, creating a relationship between the Lifetime user and the first result of this Azure AD Query.

Username rule

Each time a user signs in, the APP module will sync the user information, using the UserPrincipalName as username.

Status sync rule

As mentioned before, each time a user signs in, the APP module will try to sync its user information including the account status.

If the account becomes inactive, this will be synced on the user's attempt to login, returning an "Invalid login" message.

For users whose company field doesn't contain the word "Outsystems", a suffix will be added to there name to identify them correctly. e.g.: 'John Doe (YourCompany)'.

Disclaimer: Due to optimizations, regarding login action, the user sync may take a while to reflect in Lifetime (50min in the worse case scenario).

Hi Guilherme,

After I have installed the application in our OS11 DEV environment, the module AzureAuthProvider has errors.

We have version 2.2.1 of CryptoAPI installed (latest stable OS11 version) for our own use already.

The problem is that this version is missing the GetPriveKey server action:

Your application uses version 1.6.0, which is the latest stable version for OutSystems Platform 9.

Would it be possible to update your application to use the latest version of the CryptoAPI?

Regards,

Daniel

Hi Daniël,

Please find the latest version of Azure Authentication Provider (1.8)

We have upgraded to O11 and added support to the CryptoAPI(2.1.1 stable) and to Hashtable(0.8).


We followed the recommendations at (https://www.outsystems.com/forums/discussion/44750/safe-to-save-crypto-key-to-site-properties/) to update to latest version of the CryptoAPI.


This new version was not properly tested since we still work with O10.


Best regards,

João

Hi

Thank you for the fast response.

Regards, 

Daniel

Hi,

When defining the AAP_USER_ADAL in Azure AD, what should be defined as redirect url?

When defining the  AAP_AAD_REST in Azure AD, what should be the login url?

Regards,

Daniel

Hi Daniël,

The short answer is, it doesn't matter...

Both apps request redirect URLs but these are not used (in this implementation).

So, what we have at our configuration? We have set:

AAP_USER_ADAL Redirect URL 
 "http://OURDOMAIN.com"

AAP_AAD_REST Login URL
 "http://OURDOMAIN.com


All the best,

João


Hi João,

Thanks for the clarification.

It are mandatory inputs when defining the Azure AD applications, so that triggered my question.

Regards,

Daniel

I understand Daniël,

That's why we set the URLs with "http://OURDOMAIN.com".

I'm glad I could be of assistance.

Regards,
João

Hi,

Both applications are defined in AzureAD according the instructions.

I having some trouble getting the configuration saved without getting the error message "These parametesr were saved, but the configuration is not valid. 403 Forbidden".

I have checked that the TenantId, Native App Client Id, Web client Id, Web App Client Secret are all valid, by providing first incorrect information and receiving an error message, then passing the correct information and not getting an error message on the changed property.

The Basic User is correctly defined and a default role is created that will be assigned to users.

In Service Center I see the following error:



I have double checked the authorisations for both Azure AD apps and they are correct added and granted.

AAP_USER_ADAL:

AAP_AAD_REST:



Hello Daniël,

It seems the AAP_AAD_REST doesn't have permission to query Azure's AD Groups... 

Starting with the basics, please assure every field is "trimmed". 


The field "Infrastructure Azure AD Group" is filled? If it is, can you please clear it and try to save the configuration?

This field is optional, so, if the save action works with this field empty, you may have to tweak the AAP_AAD_REST permissions.

Also, when used, the "Infrastructure Azure AD Group" field should be filled with the name of an existing Azure AD Group.

It's possible to simulate the requests to Azure's AD using Postman (link)

Please find the PostmanCollection.zip attachment and import it to Postman.
This attachment contains a collection of requests to test AAP_AAD_REST permissions. 

After import the attachment's content, Please open the "Microsoft Request Token" request and fill the highlighted elements below: "YOURTENANTID", "YOURCLIENTID" and ""Infrastructure Azure AD Group"".

On sending the request, you will get a response with an Access_Token, as highlighted above.

Copy the Access_Code and use it as the token of the request "Graph Azure AD Groups":

If the response is something similar to this, your AAP_AAD_REST has the proper permissions; if not, you need to adjust the permissions. 


I hope this helps you. 

Regards,

João

Hi,

I have some useful new findings:

I have tested to use the graph.microsoft.com api, and with that I can retrieve groups and group membership from Azure AD. This API is the latest version and graph.windows.net is considered a legacy API.

So this raised two questions for me:

1. Why do I have problems accessing graph.windows.net, if if I grant all permissions, still no access.

2. Do you have on the planning to use the graph.microsoft.com API for the Azure Authentication Provider?

Regards,

Daniel

Hello Daniël,

At the time of the development of this Authentication provider, we had to make a decision regarding Graph.microsoft.com VS Graph.windows.net.

To our Azure AD Instance, only the graph.windows.net API was returning all the information we needed, so we used the "legacy API".

The reason behind your difficulties accessing graph.windows.net it's unknown to me.
My best guess, it's probably something related to the Azure AD configuration.

The graph.microsoft.com API doesn't provide some key values that we need. At the moment, we are not planning to support this API. 

If you really need to use the graph.microsoft.com API, you can fork this component.

Meanwhile, I've found a potential bug and I'm publishing another version of this component today.

Regards,
João