SAML 2.0 Single Logout Support

[jzheaux]

No description provided.

[fhanik]

Josh, I decided to pause the review,, to grasp more around the configuration choice.

[fhanik]

Josh, I've given you some to work with.

The number 1 take away I have is that Spring Security shouldn't release 2nd class citizen implementations. That being, I have to jump through hoops like configuring logout handlers, filters, etc to just get something as basic as logout to work. This seems to contradict the reason why we have Spring Security, like logout() in the DSL

I am happy to review the next, I need to get my environment setup for that

[fhanik]

Big ticket items

1. Metadata shows Single Logout Services even when single logout isn't enabled
2. is there one /logout that is handles logout for any type of authentication or is there /<auth-type>/logout and thus, if you support oidc,saml,oauth2,internal you have four different logout endpoints

Overall, this looks very promising and I think the above comments can be saved for future iterations as the community gets a chance to test drive it.

[rwinch]

I've provided some feedback inline

[jzheaux]

This was merged in commits efe42b9, 2f734a0, e807fae, and 6f52bab, closing the corresponding issue for each one.

[fhanik]

Thanks for the hard work on this.

[jzheaux]

I've reopened the PR to take a closer look at this comment.

[rwinch]

I've provided feedback inline.

[rwinch]

I'd prefer to leave this method off of the new interface. Instead, I think it would be worth seeing if the following arrangement would work:

• RelyingPartyRegistrationResolver does not extend Converter
• DefaultRelyingPartyRegistrationResolver can implement both Converer and RelyingPartyRegistrationResolver
• Classes that use to use Converter<HttpServletRequest, RelyingPartyRegistration> can now also allow RelyingPartyRegistrationResolver to be injected

In my mind this has the following advantages:

• RelyingPartyRegistrationResolver is kept cleaner because it does not need the convert method
• Classes that use to use Converter no longer need use instanceof checks (i.e. SamlMetadataFilter) because there can be distinct constructors/methods for the types.
• We can properly deprecate the old Converter methods/constructors
• We can properly deprecate the old DefaultRelyingPartyRegistrationResolver.convert method which eventually allows us to remove it's RequestMatcher that may be out of sync with the way the Filter is resolving the registrationId.

[jzheaux]

I believe this raises a passivity concern. For example, a current construction of Saml2MetadataFilter could look like:

new Saml2MetadataFilter(
    new DefaultRelyingPartyRegistrationResolver(repository), new OpenSamlMetadataResolver())

If RelyingPartyRegistrationResolver does not extend Converter, then Saml2MetadataFilter will need another constructor, one that takes RelyingPartyRegistrationResolver. Since DefaultRelyingPartyRegistrationResolver extends both, the constructor call is ambiguous, causing a compilation error.

One way to address this would be to add a static factory method Saml2MetadataFilter#construct(RelyingPartyRegistrationResolver, Saml2MetadataResolver). This method would be necessary in other classes like Saml2AuthenticationTokenConverter.

Or, if we add the new constructors and deprecate the old ones, those who upgrade can change to the other constructor by adding a cast like so:

new Saml2MetadataFilter((RelyingPartyRegistrationResolver) 
    new DefaultRelyingPartyRegistrationResolver(repository), new OpenSamlMetadataResolver())

or by splitting up the line (more readable anyway):

RelyingPartyRegistrationResolver relyingPartyRegistrationResolver = 
    new DefaultRelyingPartyRegistrationResolver(repository);
new Saml2MetadataFilter(relyingPartyRegistrationResolver, new OpenSamlMetadataResolver())

The initial construction I listed may be uncommon and is certainly less readable -- what are your thoughts?

[rwinch]

I think it is worth separating the controller and the view so users can customize the UI without needing to do the more complex controller logic. We can allow this Filter to optionally forward to a URL that obtains the Saml2LogoutResponse from a HttpServletRequest attribute so it can render it's own UI. This could be logged as a separate ticket. The code below would become a default ui if no forward URL was provided.