Building a composite attribute from sets of attributes
Etienne Dysli Metref
etienne.dysli-metref at switch.ch
Tue Aug 6 05:10:15 EDT 2019
[Getting back to this after a week away from work...]
On 25/07/2019 17.23, Rod Widdowson wrote:
> Without understanding what your desired endpoint is (and indeed the
> way that things are deployed in the field to any level of detail) all
> I can give is pure developers point of view.
I'll try to quickly introduce our concept of "affiliation" then. What we
call by that name is the set of SAML attributes that a university's IdP
returns about a user. In SWITCH edu-ID, we capture that set, store it,
and associate it to that same person's edu-ID account.
Today, our SWITCH edu-ID IdP is capable of releasing either SAML
attributes coming from the edu-ID account -- the "private identity" --
*or* attributes coming from *one* of the user's affiliations, at the
user's choice. What we want to do now is send, in one SAML assertion,
attributes from both the private identity and all affiliations in a way
that keeps these different attribute sets separate. In order to keep the
structure, we want to send all affiliations as JSON-structured data in
one SAML attribute.
For more context around this, have a look at our public architecture
introduction [1] or at my TNC19 presentation [2] where I explain the
data challenges and our solutions.
> If the idea is that you need an IdPAttribute whose values are
> IdPAtributes why not start with a class that implements
> IdPAttributeValue which does this?
Yes, that would be a good start. In our case, that would be
`IdPAttributeValue<Set<IdPAttribute>>`.
> You'd then need to write a Resolver and some Encoders and of course
> the parsers for these, plus of course any special filtering you need,
> but it's all public interfaces.
For resolution, should we then implement a whole
n.s.i.attribute.resolver.AttributeResolver?
Couldn't we instead get by with a custom
n.s.i.attribute.resolver.dc.MappingStrategy<SearchResult>
(n.s.i.attribute.resolver.dc.ldap.impl.SearchResultMappingStrategy being
out of bounds) that would map each search result to an IdPAttribute
containing a Set<IdPAttribute>, plus our own
n.s.i.attribute.resolver.AttributeDefinition (in case
n.s.i.attribute.resolver.ad.impl.SimpleAttributeDefinition merges too much)?
Etienne
[1] https://www.switch.ch/edu-id/organisations/architecture/
[2] https://tnc19.geant.org/sessions/#s54 (slides and video)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://shibboleth.net/pipermail/dev/attachments/20190806/974363c4/attachment.sig>
More information about the dev
mailing list