Principal Connectors
Rod Widdowson
rdw at steadingsoftware.com
Mon Mar 4 03:59:03 EST 2013
> > So the attr resolver would return an attr with value of type principal ?
Actually, on further reflection, I think not. Within the principal
resolution process we work with String and AttributeValue<java.lang.String>.
DataConnectors extra Strings from contexts which are (directly or
indirectly) contain whatever we are decoding (A NameID or a NameIdentifier
for traditional principal connection, perhaps a KrbPrincipal for Kerberos
and so forth). Resolution (and optionally filtering) proceeds as for
Attributes and we tag the attribute definition with an:
<AttributeEncoder xsi:type="enc:Principal"/>
To do the (possibly notional) encoding to that which the following stages
need. This fits in nicely to the whole way that attribute resolution works
right now and, en passant, is a good test that the structures can do what we
need to do generic attribute handling which doesn't end up as a
<saml:Assertion/>.
Somewhere along the line there is a stage to create what we need and to make
sure that there is but one of them and do the right thing with respect to
previous sessions, to my mind this is the major difference from attribute
resolution, and is probably a webflow stage after principal resolution.
There are lots of details which we need to thrash out (mostly around context
types and navigation I think), but given that this is not critical path for
the quarter's deliverables I'm not going to spend too much time on it right
now. Perhaps if we have time we could touch on it on Friday (or perhaps
not)
/Rod
More information about the dev
mailing list