Auth0 support for integration with federations like Open Athens and Shibboleth

Does Auth0 support a federation like Open Athens out of the box? Any chance to get a strategy or direction on how this can be achieved?

A quick search seems to suggest Open Athens uses SAML, which is one of the supported protocols for Auth0. You can use Auth0 both as a Service Provider and Identity Provider for SAML.

Well, we are prepared to use SAML 2.0 to upload a list of IdPs from the federation to Auth0. But then, we will also have to also synchronize any changes that may happen in the federation with Auth0. I posted this question to see if Auth0 has any plans to support this federation and manage this solution for us.

We have reached out to the customer support already and Auth0 gave us a script to read metadata from federation of 4000-5000s idps and create/update connections in Auth0. Again, there is alot of overhead in doing this. I sounds like a very common problem that many customers using Auth0 with a requirement to interact with federations like Open Athens, Shibboleth or InCommon. I am just wondering what and how other customers are solving this problem.

Hey there!

Sorry for such huge delay in response! We’re doing our best in providing you with best developer support experience out there, but sometimes our bandwidth is not enough comparing to the number of incoming questions.

Wanted to reach out to know if you still require further assistance?

I’m looking to revive this discussion to see if there’s actually an answer for this with regards to handling/syncing federation changes within Auth0:

https://community.auth0.com/t/auth0-support-for-integration-with-federations-like-open-athens-and-shibboleth/16952

I’m assuming the script looked at metadata and then used the Auth0 API to reflect the changes, but agree it’s quite a bit of overhead to add in.

Best,
Mike

Are there any updates here? We are exploring an integration with InCommon and would like to avoid a heavy lift…

Reviving this again as it was left unanswered but I suspect is still a common scenario and high on Google results. Plus, trying to understand all the different authentication/authorization protocols and how they work together messes with your head.

I have only just started looking into using SAML (OpenAthens) in conjunction with Auth0 today, so still only in the “working out all the jargon” phase and some of my assumptions may be wrong, but at first glance it appears that some element of syncing is now incorporated into Auth0 out the box.

Following this page in the docs describes how to add a connection to an external SAML identity provider so that Auth0 becomes the SAML Service Provider (aka consumer) in the chain like so:

On the last step in the section for creating the SAML Enterprise connection on that page it says you can choose “Sync user profile attributes at each login”. This isn’t quite correct…

The option isn’t available on initial creation, but once you have created the connection and gone to it in the admin UI, you will see a Provisioning tab. This has the “Sync user profile attributes at each login” toggle, and was defaulted to true for me.

There is also a “New” sync method where you can add more fine-grained syncing using the SCIM protocol, which I have not looked into at all, but looks useful.

I assume most or all of this can be setup via the Management APIs, so could be handled in a custom internal admin that we write.

Again, I haven’t been able to test anything yet, but my initial thoughts on how we might approach this are:

  • Adding the SAML providers to Auth0 should be far easier than trying to integrate SAML alongside Auth0 in our app manually, even if that comes with its own set of overheads. We still just need to use the standard OIDC Auth0 connector in our app.
  • Syncing existing user attributes on login should be sufficient (for us). If someone has changed their name, we should get that on next login.
  • We only need the most basic user data but many of the attributes are standard so the structure shouldn’t vary, only the data. which should be synced for us. If there are non-standard attributes, the external providers should really be responsible for maintaining the correct response mappings, either in their system or via an admin we provide maybe?
  • If we want to change what we attributes we read, this is probably where the syncing scripts mentioned in other posts come in. I can see that having some overhead up front to get the scripts in place, but if done correctly, once there, it should be quite quick to update and process all the relevant connections to, for example, map a new attribute.
  • I also don’t really see a way Auth0 can provide an out-the-box mechanism for this. Not all SAML connections may be relevant to be updated and different people will have different needs. It would be nice if the script mentioned in previous posts could be provided as an example in the docs tho.