<div dir="ltr"><div>I created a case <a href="https://issues.shibboleth.net/jira/browse/IDP-926">https://issues.shibboleth.net/jira/browse/IDP-926</a><br><br></div>-Christopher</div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 15, 2016 at 12:03 PM, cneberg <span dir="ltr"><<a href="mailto:cneberg@gmail.com" target="_blank">cneberg@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>>I think most people will want to merge them with real encoders and <b>down
select in attribute_filter anyway </b>- so they won't want them changed. <br><br></div>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.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 15, 2016 at 11:23 AM, cneberg <span dir="ltr"><<a href="mailto:cneberg@gmail.com" target="_blank">cneberg@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>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.<br><br> <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="<a href="http://www.mysite.com/names/$%7BPREFIX%7D$%7BID%7D" target="_blank">http://www.mysite.com/names/${PREFIX}${ID}</a>" friendlyName="${PREFIX}${VAR}" /><span><br><br>>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<br><br></span></div><div>Yes - the naming prefix is easy, its what to do with the encoders when you have a naming prefix correct?<br></div><span><div><br>>and I'm not sure if that can really be automated.<br><br></div></span><div>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.<span><br><br><resolver:DataConnector xsi:type="dc:Subject" xmlns="urn:mace:shibboleth:2.0:resolver:dc"<br> id="subject_extract"<br> principalClass="customPrincipalClass"<br> resultPrefix=""<br></span></div><div> includeEncoders=false<br></div><span><div> attributes = "uid cn sn"><br> <ReturnAttributes>ATTRIBUTE_1 ATTRIBUTE_2 ATTRIBUTE_3</ReturnAttributes><br></resolver:DataConnector><br><br></div></span><div>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.<br></div></div><br><div>-Christopher<br></div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Feb 14, 2016 at 9:34 AM, Cantor, Scott <span dir="ltr"><<a href="mailto:cantor.2@osu.edu" target="_blank">cantor.2@osu.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On 2/13/16, 1:31 PM, "dev on behalf of cneberg" <<a href="mailto:dev-bounces@shibboleth.net" target="_blank">dev-bounces@shibboleth.net</a> on behalf of <a href="mailto:cneberg@gmail.com" target="_blank">cneberg@gmail.com</a>> wrote:<br>
<br>
<br>
><br>
>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 <a href="https://issues.shibboleth.net/jira/browse/IDP-832" rel="noreferrer" target="_blank">https://issues.shibboleth.net/jira/browse/IDP-832</a> 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.<br>
<br>
</span>I created it for Misagh and just generally so that it was possible to pass back attributes from an External Authn integration.<br>
<br>
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.<br>
<span><br>
> 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<br>
> or does some other code in attribute_resolver.xml need to make them available to SP's?<br>
<br>
</span>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.<br>
<br>
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.<br>
<span><font color="#888888"><br>
-- Scott<span class="HOEnZb"><font color="#888888"><br>
<br>
--<br>
To unsubscribe from this list send an email to <a href="mailto:dev-unsubscribe@shibboleth.net" target="_blank">dev-unsubscribe@shibboleth.net</a><br>
</font></span></font></span></blockquote></div><span class="HOEnZb"><font color="#888888"><br></font></span></div>
</div></div></blockquote></div><br></div>
</blockquote></div><br></div>