Log in to AnswerLog in to Follow
LizT
41Views
13Comments
Solved
Persistent Login with Azure AD Authentication
Question

I have recently moved authentication from the IDP forge component to Azure AD Authentication via the users app as per: https://success.outsystems.com/Documentation/11/Developing_an_Application/Secure_the_Application/End_User_Management/End_Users_Authentication/Configure_Azure_AD_Authentication


 My problem is that i now can't find a way to enable persistent login so my users are now being re-authenticated after leaving pages idle for 20 (?) mins.


Can anyone suggest how i can overcome this?

0
0
on 2020-07-07
LizT
Solution

Hi All,

I had forgotten about this post!  In the end i reverted back to using the IDP component because that easily supports the persistent login approach through use of the login server action.

Back when i wrote this post i spoke with Outsystems support who put me throuh to a TSM who confirmed that persistent login was not  a feature available through the   default 'users' app integrated azure AD authentication.   They suggested this apporach as a work around, though to be honest i didn't get test it as i had to move to somethe esle.  This was their suggestion (i'd like to know if it works if you try it):


"through the usage of the factory configuration component, I've added a new configuration to increase the default session timeout along with some configurations on the Azure Portal to also persist the browser session.
By increasing the timeout to 60 minutes I was able to not to be kicked out after the default 20 minutes, see below the configuration I've added to my application:
I noticed that, for as many configurations added on the Azure side, none would work as the timeout was always 20 minutes on the platform side, and after being idle for that amount of time I was always kicked out to the Microsoft login page.
I suggest you increase this value to a number that would make sense to you on your test environment and let us know if this would be a suitable solution.

If you don't agree with that solution, I would advise you to revert back to the initial configuration (using the IdP component) as out-of-the-box, unfortunately, our configurations do not support that use case.


You can find below the xml configuration in XML so that you can copy/paste it tiy your configuration in case you decide to adopt that solution:
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output method="xml" indent="yes" encoding="UTF-8"/>
<xsl:template match="@*|node()">
<xsl:copy>
<xsl:apply-templates select="@*|node()"/>
</xsl:copy>
</xsl:template>
<xsl:template match="/configuration/system.web/sessionState">
<xsl:copy>
<xsl:attribute name="timeout">60</xsl:attribute>
<xsl:apply-templates select="@*|node()"/>
</xsl:copy>
</xsl:template>
</xsl:stylesheet>

liz

See solution in context
0
0
on 25th Mar

Thanks Liz!

I will give this a try soon and share results.

-Tolli

0
0
on 25th Mar
Nordin Ahdi
mvp_badge
MVP

Hi Liz,

The default .NET session timeout is 20 minutes. If you want to enable persistent login you can review this documentation. 

The configuration of the default duration of a persistent login session depends on what type of application you have enabled persistent login for. For Traditional Web Application you can use the Factory Configuration component, while for Reactive Web Applications and Mobile Apps you can configure the Max Idle Time parameter in Service Center.

Hope this helps.

Regards,

Nordin

0
0
on 2020-07-08

Nordin Ahdi wrote:

Hi Liz,

The default .NET session timeout is 20 minutes. If you want to enable persistent login you can review this documentation. 

The configuration depends on what type of application you want to enable persistent login for. For Traditional Web Application you can use the Factory Configuration component, while for Reactive Web Applications and Mobile Apps you can configure the Max Idle Time parameter in Service Center.

Hope this helps.

Regards,

Nordin

Hi Nordin,

I read the persistent login article but that refers to enabling it by using the user_login action.  As login is  performed as Single sign on via Azure AD this action isn't used where i can configure it as it configured in the 'users' app.  

I also have noted the factory configuration timeout option but that related to timeout not persistent login which are 2 different things.  For example, If a (external) user is logging in manually to an app (not via SSO) then the timeout needs to remain as 20 mins but where  a user accesses an app via SSO then persistent login should apply.

1
0
on 2020-07-08
Nordin Ahdi
mvp_badge
MVP

Hi Liz,

Thanks for the more detailed explanation. 

I was not aware you don't use the User_Login action with Azure AD authentication. As I haven't used Azure AD authentication myself, I don't know of a different approach to persist the login session.

I have edited my earlier post, as I meant to say a persistent login session also has a default duration which is customizable using either Factory Configuration for TWA or via Service Center for RWA and Mobile. Thanks for correcting me.

Maybe someone on the Forum who has more experience with Azure AD will be able to help you out. Otherwise you could always open a support case with OutSystems and ask them for assistance in this matter.

Regards,

Nordin

1
0
on 2020-07-08

Hi Liz,

I have also just recently enabled SSO via Azure AD and am facing the same timeout issues as you describe.

Did you figure out a way to address this or some workaround that you can share?

Best regards,
Tolli

0
0
on 24th Mar

Hi Tolli,

I don't know if you can do persistent login using IdP component, however you can do it using Auth0 component.

Auth0 uses OpenId while IdP uses SAML. With OpenId Connect you can implement the Authorisation Code Flow and silently authorize the user when the session expires. Additionally you can request a refresh token and use it to request a new access token whenever the current access token is about to expire. 

0
0
on 24th Mar

Hi Ivo and thanks for the reply!

We're actually using Auth0 as well here, but not with OutSystems though.  I agree using OIDC and ACF+refres tokens would be a good fit.

Still I am hoping similar can be achieved with Azure AD for the sake of simplicity of our stack.  We have until just recently only been working with the Users module for user management (as we have had mostly open-for-all applications on internal network), so we never went down the LDAP route.

That's why the Azure AD option was a great fit as it reduces the login friction and we can use Azure AD for security policies - and on top users are created/updated on-the-fly at login.  We're using groups claim in the SAML message so users get their appropriate roles on first login (with all management on Azure AD side), and no need for other user synchronization.

From my first look at the Auth0 component that's all out of reach, so replacement would entail some larger effort.

-Tolli

0
0
on 24th Mar

Replying to Tolli's comment on 24 Mar 2021 23:16:27

Hi Tolli,

You can use OpenID Connect with Azure as well and implement the the Authorisation Flow. We are using it in our project, where we have implemented this flow with refresh tokens.

In Azure you can customize the group claims for your application:

IG

0
0
on 25th Mar

Replying to Ivo Gonçalves' comment on 25 Mar 2021 08:05:32

Hi again Ivo,

(Sorry if I'm double posting this - I wrote a reply this morning that I can't find now...)

Great to hear you've succeeded in connecting OutSystems to Azure AD using Open ID Connect (OIDC)!

I'm curious about the details, would highly appreciate if you could elaborate a bit on your setup.

  1. Are you using the Auth0 component you referred to earlier to connect to Azure AD, or something else?
  2. Are you using OIDC only for those users, or are you using it in conjunction with the SAML method supported by the Users module + Azure AD?
  3. If you're using OIDC only, are you provisioning users within the login flow, or do you do that somehow seperately?

Again, I really appreciate your input on this, thanks in advance!

Best regards,
Tolli

0
0
on 25th Mar

Replying to Tolli's comment on 25 Mar 2021 16:34:36

Hi Tolli,

  1. Yes, we are using Auth0 forge component
  2. We only use OIDC
  3. Users existing in the HR systems end up in Azure AD, then we have built an application that runs every few minutes to synchronize the users from Azure to OutSystems. For that we use the delta query for users from graph api. We use the delta query because OS platform does not support yet exposing PATCH methods on REST APIs, otherwise we could have used SCIM.
1
0
on 25th Mar

Replying to Ivo Gonçalves' comment on 25 Mar 2021 20:58:28

Thanks :)  Sounds like a neat approach.  We're already actually using OutSystems for syncing employee data between a few systems so that should entirely be within reach for us.

FYI I see that PATCH support is estimated Q2 2021

1
0
on 26th Mar
ronny
Champion

Hi LizT,

I also encountered this issue before. In my case, i use the following forge and put in my common footer. It will alert the user to extend the session before the session timeout. It will also inform the user to login if the session is already timeout


https://www.outsystems.com/forge/component-overview/1880/session-expiration-warning


Hope it helps

1
0
on 25th Mar
LizT
Solution

Hi All,

I had forgotten about this post!  In the end i reverted back to using the IDP component because that easily supports the persistent login approach through use of the login server action.

Back when i wrote this post i spoke with Outsystems support who put me throuh to a TSM who confirmed that persistent login was not  a feature available through the   default 'users' app integrated azure AD authentication.   They suggested this apporach as a work around, though to be honest i didn't get test it as i had to move to somethe esle.  This was their suggestion (i'd like to know if it works if you try it):


"through the usage of the factory configuration component, I've added a new configuration to increase the default session timeout along with some configurations on the Azure Portal to also persist the browser session.
By increasing the timeout to 60 minutes I was able to not to be kicked out after the default 20 minutes, see below the configuration I've added to my application:
I noticed that, for as many configurations added on the Azure side, none would work as the timeout was always 20 minutes on the platform side, and after being idle for that amount of time I was always kicked out to the Microsoft login page.
I suggest you increase this value to a number that would make sense to you on your test environment and let us know if this would be a suitable solution.

If you don't agree with that solution, I would advise you to revert back to the initial configuration (using the IdP component) as out-of-the-box, unfortunately, our configurations do not support that use case.


You can find below the xml configuration in XML so that you can copy/paste it tiy your configuration in case you decide to adopt that solution:
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output method="xml" indent="yes" encoding="UTF-8"/>
<xsl:template match="@*|node()">
<xsl:copy>
<xsl:apply-templates select="@*|node()"/>
</xsl:copy>
</xsl:template>
<xsl:template match="/configuration/system.web/sessionState">
<xsl:copy>
<xsl:attribute name="timeout">60</xsl:attribute>
<xsl:apply-templates select="@*|node()"/>
</xsl:copy>
</xsl:template>
</xsl:stylesheet>

liz

0
0
on 25th Mar

Thanks Liz!

I will give this a try soon and share results.

-Tolli

0
0
on 25th Mar
Community GuidelinesBe kind and respectful, give credit to the original source of content, and search for duplicates before posting.