No subject

[cneberg]

>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 made a bad assumptions there.  It would currently be hard to downselect
in attribute_filter because I don't know if it has the concept of merging
or comparing multiple attribute names and their values, and the attribute
source entity id of has been lost - which I think would be necessary to
choose between attributes, maybe from entityID1 I prefer their value, and
from EntityID 2, I prefer the local version, or merged, etc.   It's a whole
separate topic and its beyond my current use cases since I don't need to
merge attributes.

On Mon, Feb 15, 2016 at 11:23 AM, cneberg <cneberg at gmail.com> wrote:

> 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/e196e28e/attachment-0001.html>