Proposal to resolve entities by role+protocol

[Brent Putman]

On 12/10/15 7:26 AM, Marvin Addison wrote:
>
>  
>
>     And I had a good chunk of the specific endpoint indexing plugin
>     impl done also, that does the indexing by sub-path segments for
>     partial path matching like is discussed in IDP-701.
>
>
> Partial matching would definitely provide a needed feature. I had
> convinced myself that filtering by role and protocol was needed as
> well to prevent collisions between SAML and CAS protocol entries.

It was already planned to include the role type QName as part of the
index key, and I floated the question in OSJ-129 whether it should also
include protocol.  Thinking about it more now, perhaps it should, for
the reasons you state.

I hadn't really given it much thought, but I guess the expectation here
is that in the metadata the CAS endpoints would be in a separate
SPSSODescriptor from say the SAML ones, partially because of the
protocol scoping issue? 

I only ask because we typically *don't* do that for SAML, v1 vs v2 vs
the legacy "Shibboleth" protocol - those are usually all in the same
SPSSODescriptor.  There, the endpoint Binding URI serves (practically)
to distinguish SAML 1 from SAML 2, etc.  The same would be true of CAS,
I guess.

But now I'm thinking we should consider the Binding to be part of the
index, either instead of or in addition to the containing
RoleDescriptor protocol. Needs more thought.

>  
>
>     I think mostly what remained was deciding on what the endpoint
>     index input criteria would look like - reuse existing multiple
>     critieria or create a new compound Criterion holding data for
>     just this case.
>
>
> I think I'd need to know some of the new use cases to make a comment.
> I like the idea of reusing what we have, but that's more of a design
> philosophy than a practical recommendation.

I was leaning towards re-use of existing also.  Just needed to work out
whether we already had everything we needed.  We might need to add some
new granular Criterion(s) in any case.

>
>     Only reason why I pulled it was: We weren't going to actually use
>     it in 3.2.0 (for neither your CAS stuff nor inbound SAML artifact
>     binding). I didn't want to unnecessarily and prematurely commit
>     to the APIs, without having a chance to really test them out "for
>     real".
>
>
> Well, I need _something_ for IDP-701, so I expect that would exercise
> the APIs if nothing else.
>

Absolutely.  Both the CAS stuff and SAML artifact are the initial
drivers here, so I was just waiting til we release one or both of those
to publicly commit the framework, in part so that those drive real
testing beforehand.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20151210/b6b4dd88/attachment.html>