Skip to content

Allow definition of metadata URL for SAML plugins #280

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 4 commits into from

Conversation

saibot94
Copy link

We at CERN require SAML metadata URLs to be different than the ones provided by parsing the entityId. This comes from a need to support an old and new system concurrently, both of them having the same `

This PR extends the config and allows it to be extended with a custom_metadata_url.

@ioparaskev
Copy link
Contributor

I'm not sure I understand the purpose of this PR. Why not generate the metadata as described here and use nginx/apache to serve them under any path you want?

Besides that, seeing the diff and reading the documentation I think that it's not clear and can be confusing what URL will be used in the end to serve the metadata. To be more specific, the documentation says:

| entityid_endpoint | bool | true | whether entityid should be used as a URL that serves the metadata xml document

entityid should be used as a URL that serves the metadata xml document

and in your diff it says:

| custom_metadata_url | string | custom_metadata/endpoint.xml | custom metadata endpoint, in the case you want to serve your metadata on an endpoint other than the entityIds path. Will not get populated if the attribute is missing or empty, or when the entityid_endpoint property is not true. |

serve your metadata on an endpoint other than the entityIds path

So you set the entityid_endpoint to mark that entityid should be used as a URL that serves the metadata xml document and you set custom_metadata_url to some other URL to serve your metadata on an endpoint other than the entityIds path. So the second option overrides the first option which is confusing I think.

@saibot94
Copy link
Author

Thanks for the comments @ioparaskev. We just wanted to have something simple to configure, without necessarily requiring nginx / apache in front of it.

Anyway, I understand your concern on the confusing aspect of the code. I'll change the implementation so that the custom_metadata_url is not dependent on the entityid_endpoint. I might also change the name to custom_metadata_endpoint to make it more consistent.

@c00kiemon5ter
Copy link
Member

c00kiemon5ter commented Sep 25, 2019

@saibot94 call it metadata_endpoint and we may make this the primary configuration option to serve metadata.

@saibot94
Copy link
Author

saibot94 commented Sep 25, 2019

I renamed the endpoint and changed the description in the docs. Let me know if it makes sense, thanks!

@c00kiemon5ter
Copy link
Member

So, we now have to options that seem similar; they both handle the URL that will serve the metadata of the corresponding plugin. These are: entityid_endpoint (old) and metadata_endpoint (new).

entityid_endpoint came by the requirement of eIDAS to serve metadata at the location indicated by the entityid. This means that eIDAS specifies that the entityid MUST be a URL.

While this is good practice it is not specified by the SAML specification. The SAML specification says that the entityid is a URI. Any resource identified can be used, and in practice this has been used and deployed with urn:oid and other types of ids.

For those entities there is no way to specify a URL that will serve the metadata. The metadata have to be generated separately and served by other means. This is doable and we have been working like this was for a long time.

The new option metadata_endpoint covers exactly this need. It solves the problem of serving the metadata for an entity that defines an entityid that is not a URL. The use case of CERN seems different, but if one considers the entityid as just an id, then it is exactly the same problem. The fact they define the entityid as a URL doesn't make the use case any less valid. URLs are subsets of URIs. They define a URI and they need a URL to serve the metadata.

At the same time metadata_endpoint is more general than entityid_endpoint. This means that it can cover the use case of entityid_endpoint and thus it can replace it. So, I propose that we go forward with that. We introduce a new option, and then we'll deprecate the old one.

@saibot94
Copy link
Author

Hi @c00kiemon5ter! I wanted to ask if there's any status update on this pull and #279 . We'd require this feature available relatively soon. :)

@c00kiemon5ter c00kiemon5ter changed the title Allow definition of custom metadata URLs for SAML plugins Allow definition of metadata URL for SAML plugins Oct 29, 2019
@saibot94 saibot94 closed this Apr 24, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants