Contexts and attribute operations
Rod Widdowson
rdw at steadingsoftware.com
Mon Jan 6 10:02:11 EST 2014
> >1) I propose we ditch all the Issuer-metadata related filters.
>
> I'm in favor.
I'll prepare the code, but look for closure on Friday (if we do not agree in
here sooner),
>> Are context hierarchies liable to ever change on a per-flow basis?
>
> They'll never change for a given flow definition, but I thought the point
> of the strategy function was to allow them to change across different
> flows.
Right - but this means that we cannot inject the strategy as part of the
filter definition creation. If we put it there, then once the filter is
configured and initialized there will be only one way to get from a
FilterContext to a SAMLMetadatContext. So the strategy has to be injected
when the flow is put together. This is where we currently inject the
strategies for locating the SubjectContext and RelyingPartyContext. But
this in turn means that the only place we have to put information which the
filters can see is the FilterContext.
So we then have two options - just put the information we may need
(entityID, SSOEndpoint) directly into the FilterContext - just as we do for
Principal and so forth, or put a strategy into the FilterContext being how
to get from itself to the SAMLMetadatContext - the latter is slightly more
cumbersome but would save cycles in the general case where we don't care
about the SP's metadata, hence I favour it.
But either way, my idea of having a context strategy configured as part of
the Filter Definitions just won't work.
/Rod
More information about the dev
mailing list