[cneberg]

I created a case https://issues.shibboleth.net/jira/browse/IDP-926

-Christopher

On Mon, Feb 15, 2016 at 12:03 PM, cneberg <cneberg at gmail.com> wrote:

> >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/20160222/6d918b4b/attachment.html>