ADFS 3.0 - Conditional based session experience? RRS feed

  • Question

  • We are some way away from exploiting Azure AD, Conditional Access Policies and MFA. So at present we have to make do with our on-premise ADFS 3.0 and its capabilities. A question has been posed about SSO for a third-party SaaS solution (web app) that is publicly available in mobile app stores and accessible through a browser. Any advice would be very much appreciated.

    The concern is focused on how we handle the SSO experience (particularly session timeout) for people using trusted and untrusted devices. As far as the web app the only session timeout configuration option is for LDAP, not SAML.

    Given the data exposed in the app, for trusted (managed) devices where we control who has access or when the screen locks we're comfortable with the session timeout we've set on the relying part config.

    For untrusted devices, sessions on personal (non-MDM) mobile or personal or shared PCs then is there scope to control the session timeout within ADFS? I'm not sure that logic or control on a relying party exists.

    It would be interesting to understand how others manage the challenge of trust for SSO. Up until now we've really only had to managed trusted apps (not publicly accessible) with the only considerations being controlling Issuance Authorisation through an AD group and enforcing MFA when on external networks.

    Wednesday, June 5, 2019 10:16 AM

All replies

  • If your application is an Enterprise Application in Azure AD, there is no way for ADFS to know that the users are requesting access to it. Everything in Azure AD is encompassed in the same relying party trust. ADFS see the same token request whether the user is accessing Sharepoint Online, Exchange Online... or any Enterprise Applications. This is why Conditional Access has to be done at the Azure AD level.

    If your application is a relying party trust in ADFS, and published through a WAP server, you can configure an Idle Timeout: https://docs.microsoft.com/en-us/powershell/module/webapplicationproxy/set-webapplicationproxyconfiguration?view=win10-ps

    If your application is a relying party trust in ADFS but you do not publish it through WAP, the only thing you can do at the ADFS level is to force re-re-authentication. But that would be valid for everyone. You could use device authentication on the ADFS level and manage different SSO lifetime for users on registered devices. But on a hybrid AD environment it is a bit painful to set-up and maintain (not to mention it also depends on the devices' OSes).

    Ultimately, session timeout can always be implemented at the application level. The application can trigger a sign-off (redirection to the correct URL for that purpose). This can be achieved with a javascript tracking the user activity. It would be at the discretion of the application developers to implement it.

    Alternatively, if the application has some compatibility with Cloud App Security, you might be able to control the session that way. The Cloup Add Security would act as a broker between the client and the app (and you can enable it only for non managed devices via Azure AD conditional access policies). But your application have to be compatible somehow. More info here: https://docs.microsoft.com/en-us/cloud-app-security/what-is-cloud-app-security

    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

    Thursday, June 6, 2019 7:42 PM
  • Thanks Pierre, an excellent response.

    My assumptions below based upon the following:

    • Our WAP is running on Windows Server 2012 R2 (ADFS 3.0) and there's no option for the idle timeout
    • We're not using device registration, so at present cannot customise the experience for trusted/untrusted devices
    • Some of the apps have no session timeout customisation. For example the app I'm currently looking at has no options for SAML but does have timeout options if we were to use its LDAP authentication option
    • Our WAP (edge) token has a timeout set to 0 (60 mins?)
    • Our Web SSO timeout is set to 480 (8 hours)
    • We have KMSI enabled with the default timeout of 1440 (24 hours)
    • The relying party trust is set to 0 (60 mins?)

    My understanding, which could well be off track, is that the Web SSO timeout (subject to KMSI) is ultimately going to dictate the timeout and prompt to logon. That certainly seems to follow with the experience for a test relying party, the session appears to persist for 24 hours.

    For an publicly available application where the data needs to be secured we would wish to have an aggressive re-authentication schedule. Ideally external and untrusted devices would have the most aggressive timeout but neither seem to be an option for us in our current state.

    If we set the WAP token to 5 mins, the Web SSO to 30 mins, KMSI to 30 mins and the RP to 30 mins. The assumption is that both internal and external logon would be required after 30 mins. The reason being that the Web SSO (global) will extend the RP lifetime and refresh the WAP token automatically.

    To bring the Web SSO token down to a reasonable level will impact all existing relying parties.

    What's the best/simplest way forward? Would the move to ADFS 4.0 and the WAP Idle Timeout be a sufficient to control users from outside the corporate LAN/WAN? I guess that's a question we need to answer. I would expect this will drive the move to Azure AD...

    Monday, June 10, 2019 11:46 AM