简体   繁体   中英

Handling failure of SAML IdP

I'm considering using SAML, SSO to authenticate users accessing a web-based application. Azure AD, provided with Office 365, would be the Identity Provider.

Downtime of Azure AD would render that application inaccessible for users who would need to re-login.

What are the best practices for handling outage / unreachability of SAML IdP in such setup?

Thank you!

The SP has nothing to do with the IdP after authentication other than to re-enforce authentication after a policy at the SP has been triggered. eg user sessions at the SP can only be for an hour, after which the user must re-authenticate at the IdP. Also, the expiration time of SAML attributes should enforce re-authentication at the IdP.

In order re-authenticate, the SP needs to know where to send the browser, ie the IdP's sso endpoint url. That is normally in the IdP's SAML metadata. Sending the browser direct to that sso url when Azure is offline isn't really the SP's problem.

However, if the SP wanted to help the user, it could extend the session at the SP until the IdP is back online.

The IdP's metadata url can be seen here under

The tenant-specific endpoint

ie

https://login.microsoftonline.com/ /FederationMetadata/2007-06/FederationMetadata.xml

To detect an offline IdP, the SP could issue a HEAD request to that url at the IdP prior to sending the browser to the IdP's sso url. If the HEAD request failed because Azure is offline, inform the user and possibly extend the SP session.

However, ultimately the IdP being offline is not the SP's concern. The SP's concern is to enforce its authorisation policies. If the SAML attributes have expired then the user must re-authenticate. If that's not possible due to an offline IdP, it's debateable whether an SP should compensate by "bending the rules" on authorisation. eg an IdP may only issue SAML attributes that last for an hour for a sensitive resource such as medical records. The SP should honour those attributes and not extend the session for the user if the IdP is offline.

If you are concerned about the availability of Azure AD, you can integrate an on premise domain controller to your domain . Your application can still use Azure AD as an IdP, and revert to the local infrastructure in case of connectivity shortage.

According to this article, the monthly SLA for Azure AD will be updated from 99.9% to 99.99%, which means around 4 minutes and 22 seconds of downtime per month.

Now considering this, I don't see a good way of "handling" such a downtime, other than just informing the users about a temporary issue, because of 2 reasons:

  • Azure AD most probably will not be down so often (every month for 4 minutes)
  • If you try to build your own workaround, you may loose the security benefits guaranteed by direct authentication via Azure.

You can measure how many users authenticate on your website per minute to make a short assessment of an eventual impact.

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM