Document relationship between registrationId, EntityID, and resolving a relying party

[jzheaux]

Based on #12664, the documentation around SAML 2.0 URIs could be clearer.

Specifically, it should be clearer when and why setting a registrationId or configuring relying party lookup is important. One reason that it is important is that RelyingPartyRegistrations defaults the registrationId to be the asserting party's entity id, which cannot be placed in the path of URIs like /authenticate/{registrationId}. Either the relying party lookup strategy needs or the registration id needs to change.

[stnor]

Regarding this, it's not practical to "invent" new id:s for 200 IdPs in a large federation. The business key in the metadata is the entityId, right?

Based on your comment in #12664, I guess you're saying that the id could be generated? Keep in mind that I need to provide a persistent url for the customers using one particular IdP so it cannot change over time.

[jzheaux]

@stnor thanks for the feedback, but I think this strays from the focus of this issue which is to improve the documentation.

I'm very happy about your interest in migrating to Spring Security, and I want to help. So far, I realize that I've been responding to your thoughts and questions wherever they are appearing. Going forward, please feel free to open a ticket if you have an enhancement you want to discuss or a bug you want fixed. Otherwise, you can engage me and the team over chat on Gitter and/or StackOverflow. That will help keep each ticket focused on its primary task.

[jzheaux]

Also note that as part of the documentation improvement here, spring-projects/spring-security-samples#122 was added.