Extracting Values from a Custom Principal

[cneberg]

I'll explain my use case further in case it could be made more generic.
I'll have maybe a dozen attributes with names which would overlap with
existing names from the ldap data connector.  Things like cn, email, sn,
uid, phonenumber, etc.   These versions come from another IDP to my
authenticator which were key/value pairs.  The reason I would want to
prefix them before releasing them was is so they don't overlap, but I don't
care too much about the encoded value format, there is no accepted format
for prefixed attributes anyway - I just need them to be unique.  I choose
"remote-" as my prefix to signify they didn't come from the local ldap.
In my head I used a format like below when I defined them each individually
in the attribute resolver.

 <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="
http://www.mysite.com/names/${PREFIX}${ID}" friendlyName="${PREFIX}${VAR}"
/>

>I think you have cases where you might want to generate new attributes
with a naming prefix, for example, and I was thinking maybe we could build
that in

Yes - the naming prefix is easy, its what to do with the encoders when you
have a naming prefix correct?

>and I'm not sure if that can really be automated.

I believe the prefixed encoders issue is secondary but I'll muse anyway.
How about you only encode the return prefixed-attribute name, and don't
prefix the attribute encoders you leave them as-is.  There is no standard
for prefixed encoders strings anyway.   Then let the caller decide if they
they are to be included (assuming they are really attached at all - lots of
use cases probably won't attach them).   I think most people will want to
merge them with real encoders and down select in attribute_filter anyway -
so they won't want them changed.   I don't think my use case is the
standard use case - I really do want to prefix the encoders but that's ok I
can create my own custom class and attach attributes with encoders which
already of the correct prefixed-format.

<resolver:DataConnector xsi:type="dc:Subject"
xmlns="urn:mace:shibboleth:2.0:resolver:dc"
                        id="subject_extract"
                        principalClass="customPrincipalClass"
                        resultPrefix=""
                        includeEncoders=false
                        attributes = "uid cn sn">
         <ReturnAttributes>ATTRIBUTE_1 ATTRIBUTE_2
ATTRIBUTE_3</ReturnAttributes>
</resolver:DataConnector>

If something even more generic is needed - instead add a
getAttribute(String, returnAttribute, String prefix) method to
IdPAttributePrincipal and tell implementers to subclass it fixing the
encoders as necessary to create the encoders with the correct format based
on the returnAttribute and prefix the caller wanted to use.  I question how
useful that would be since there is no standard format, and if we picked
one, someone would want a different one.

-Christopher

On Sun, Feb 14, 2016 at 9:34 AM, Cantor, Scott <cantor.2 at osu.edu> wrote:

> On 2/13/16, 1:31 PM, "dev on behalf of cneberg" <
> dev-bounces at shibboleth.net on behalf of cneberg at gmail.com> wrote:
>
>
> >
> >Scott said he had implemented a custom principal to support custom
> attributes from external auth.   He didn't remember if was implemented
> based on a Map.   I  looked if he was referring to
> https://issues.shibboleth.net/jira/browse/IDP-832 and
> idp-authn-api/src/main/java/net/shibboleth/idp/authn/principal/IdPAttributePrincipal.java
> its not based on a Map but only a single attribute/value pair.   So I'm
> re-thinking the design but I need to know more about how it works in
> practice.
>
> I created it for Misagh and just generally so that it was possible to pass
> back attributes from an External Authn integration.
>
> I don't believe I have (yet) actually created any resolver plugins to
> operate on them, but the natural thing to do would be to just write a
> DataConnector that pulls them all out as the result of the connector.
>
> >   If an external auth plugin attaches a few of these principals to a
> subject they will automatically be available encoders and all to release in
> attribute-filter.xml
> > or does some other code in attribute_resolver.xml need to make them
> available to SP's?
>
> Well, nominally the latter. But I need to review some of the resolver
> internals. In theory if the IdPAttribute were actually created with
> AttributeEncoders attached, it could maybe be directly exposed somehow
> without layering another attribute on top of it, but I don't think it's
> that simple right now.
>
> I think you have cases where you might want to generate new attributes
> with a naming prefix, for example, and I was thinking maybe we could build
> that in. But I agree, it's unwieldy to have to create a whole separate set
> of definitions on top. But no matter what, they can't leave the resolver
> and show up in SAML unless there are encoders attached, and I'm not sure if
> that can really be automated.
>
> -- Scott
>
> --
> To unsubscribe from this list send an email to
> dev-unsubscribe at shibboleth.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20160215/206b8728/attachment.html>