Generalize RP Selection Mechanism

[Marvin Addison]

>
> Any SSO protocol is trivially mappable to SAML metadata


To be honest, I stopped when I saw
that RelyingPartyConfigurationSupport#byGroup was backed by something
called "SAMLMetadataContext" that I took at face value to be SAML-specific.
Maybe it's just a naming thing, but names matter. If it's intended to be a
general API that can be implemented by any SSO protocol, it should have a
name that reflects that purpose.


> I'm not sure
> why the simpler solution isn't just to generate that metadata, because if
> you need to be able to supply the information at runtime you're going to
> have to feed in that exact information somehow.
>

Perhaps you're right -- I'll consider that route.


> I think you're suggesting that we put a group collection into the RPC and
> then just have an action in the SAML flows to copy the group data from the
> metadata over to that collection?
>

Correct.

I don't think that's a bad idea, but my question is how you're planning to
> populate that in a different way?


I have some CAS-specific contexts that dangle off PRC that I would use.


> Because whatever that way might be, it
> could just generate the necessary metadata. Both end up in about the same
> place, but generating the metadata drives a lot of other useful code.
>

That's a fair analysis. Looking more closely at SAMLMetadataContext, I see
that I can probably create a CAS-specific EntityDescriptor, but the
*Descriptor classes are very XML-oriented and contain some SAML-specific
concerns. I don't see any showstoppers yet, but I'm not sure this will be
easier to implement. But I'd trade a harder implementation for easier
configuration any day, so I may go this route.

M
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/dev/attachments/20141113/051710b3/attachment.html