<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Any SSO protocol is trivially mappable to SAML metadata</blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I'm not sure<br>
why the simpler solution isn't just to generate that metadata, because if<br>
you need to be able to supply the information at runtime you're going to<br>
have to feed in that exact information somehow.<br></blockquote><div><br></div><div>Perhaps you're right -- I'll consider that route.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I think you're suggesting that we put a group collection into the RPC and<br>
then just have an action in the SAML flows to copy the group data from the<br>
metadata over to that collection?<br></blockquote><div><br></div><div>Correct. </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I don't think that's a bad idea, but my question is how you're planning to<br>
populate that in a different way?</blockquote><div><br></div><div>I have some CAS-specific contexts that dangle off PRC that I would use.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Because whatever that way might be, it<br>
could just generate the necessary metadata. Both end up in about the same<br>
place, but generating the metadata drives a lot of other useful code.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>M<br><br></div></div>