I’m currently trying to use Auth0 as a service provider. The identity provider I’m connecting to has a number of requirements that must be included within the saml metadata which can be found here: SAFIRE
I’ve been able to modify the entiyID to contain a URL rather than the URI that auth0 provides by calling the Auth0 Management API patch_connections_by_id and specifying a "entityId":"https://myurl.com" and this worked correctly. One of the other requirements from the identity provider is to include an <md:Organization> element, where:
<md:OrganizationName> MUST reflect the legal name of the juristic person.
<md:OrganizationDisplayName> MUST be present adn SHOULD reflect a commonly known or shortened version of the organisation’s name
<md:OrganizationURL> MUST contain the organisation’s web site address.
I tried to add this to the management API in the same way that I did for the entityId but this didnt work. There are a few other custom fields that I will need to add next but I suspect the process will be similar to adding the md:organization.
To my knowledge it is not possible to add custom attributes to the metadata automatically generated by an Auth0 tenant; it’s possible to influence the values that are used by default like changing the entity identifier as you did, but adding specific attributes I don’t believe to be possible.
I confess I never checked to make sure if this would be going against specification or not and if any identity provider performs check to mandate that if metadata is provided by URL the URL needs to be in control of the same domain as the actual service provider. In other words, it may be possible for you to provide your own endpoint that dynamically obtains the metadata from the tenant and then augments it with the required attributes.
So this means that I would need to write some kind of custom middle ware that would modify the xml document from auth0 and then feed it to the identity provider? This sounds like such a mission to be honest! Can you think of any other easier alternatives to this problem or other ways that I could configure the system such that I could provide my own metadata with auth0 acting as the SP?
Yes, I agree with your that the previous would be some overhead; the dynamic approach was just the most complete, but you can also check if the identity provider allows to upload the XML itself as metadata in which case given the attributes to be added are non-functional from a protocol perspective then you could just download the current metadata and modify it manually.
For sure I could modify it manually but then future requests against the identity provider will not have this additional meta data. I will contact the identity provider and check if this is acceptable. In the even that it is not do you have any recommendations to how I could go about implementing the dynamic approach?
In general, although having metadata periodically checked this does not always happen; for example, some identity providers will allow you to configure the trust relationship manually even without metadata. Others may require metadata, but will only use it for setup time and then won’t query it again even if you provided them with an URL instead of raw XML data.
As you said you need to check with them what are their specific requirements; do they require metadata once or do they need something they can programmatically check. If they need an URL, then the middle-man approach depends on what do you already have. It’s likely that you may have a back-end for something else so you would need to check if you could reuse that service to expose an endpoint that does that customization. Ideally you should use a server-side technology with good and easy to use XML parsing libraries because you’ll need to parse the metadata from Auth0 and then augment it.