Challenge

One of the most common complaints by users in organizations that have multiple applications that are been used is about the need to have a different password for each application and those passwords cannot be the same. Because there are different security rules which, for instance, determines that users of application A must have a password with 8 characters, one capital letter and no symbols are allowed, and application B requires a password with the same rules plus a symbol. That said using the same password might be challenging.

Approach

This is one of the reasons why we have decided to implement the Azure/SAML2.0 authentication in our organization. Michael De Ruijter as System Engineer to set up all the systems and I, as Software Engineer to implement the ability to get a connection from the applications, have decided to share our implementation experience.

This is the second part of the implementation series, you can read the first one here. There you can find the explanation of what we are talking about and what you need to do to be able to start implementing it.

What did we do?

So, as we already told before OutSystems supports natively the Azure/SAML2.0 authentication since version 11.0.542.0 (Jul.2019 CP2). But this is only valid for traditional web applications and not yet available for reactive web applications.

The changes that you will need to do in the case of a mobile application will be tackled in the next article of this series.

For the login process, no extra development is needed, as soon as you set up your users module to use SAML messages it will automatically make use of the Azure authentication for all traditional web applications that were using the users module as an user provider.

Easy peasy, right?

Not too fast, hold your horses because we are going to need to do a little development to have your login and logout flow fully working and integrated with Azure.

The OutSystems documentation describes what we need to do to make the logout flow work as expected. Those steps are needed because the login is changed automatically, but the default logout flow just logs out the internal user of the OutSystems environment and then performs a redirect to the login page.

At that point Azure does not know anything about the requested logout, so basically what we need to do is to get the unified URL, that URL is the IdP logout URL. When calling that URL, we will tell Azure that we want to logout a user, if the unified URL is empty, we just need to logout the internal OutSystems users by using the standard User_Logout action and then redirect the user to the unified login URL.

We can find both actions to get the unified URLs inside the Users module:

So, if you follow the steps that are in the documentation your logout flow for traditional web applications should look like this:

I would highly recommend that you think about the centralization of this flow, to avoid the need to reimplement that flow in every traditional web application that you have, or you will have in the future.

One thing to highlight again is that integration will only work as described if your application has the default users module as a user provider. If you have a custom user provider another approach will be necessary.

As you can see it is not a nightmare, but you will need to follow all the steps to have a proper authentication flow in your environments and to guarantee that this will benefit the users instead of giving them more headaches.