<div dir="ltr">Thank you both. The decision to add encodings is one I've forgotten the rationale for, but seemed wise at the time. It definitely wasn't and obviously was based on a lack of information. <div><br>
</div><div>We're so limited on resources dealing with Shib that convincing anyone to audit and strip those from our attributes now--and ensure all our SPs still work--seems like an a huge waste of resources. But... with such a clear-cut error in judgement, I think I can make the case.</div>
<div><br></div><div>Again, thanks.</div><div><br></div><div>Chris</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jun 24, 2014 at 9:47 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"><div class="">On 6/24/14, 12:19 PM, "Christopher Peters" <<a href="mailto:cjpeters@uci.edu">cjpeters@uci.edu</a>> wrote:<br>
<br>
>Last year, we made the somewhat unwise decision to add encodings to<br>
>attributes to support both the URN:MACE and OID namespaces. That is to<br>
>say, for all our core attributes each AttributeDefinition has two<br>
>encoders per protocol. e.g.<br>
<br>
</div>There are no urn:mace names for attributes in SAML 2. Not one that I can<br>
think of offhand.<br>
<div class=""><br>
>So far, we have been working around the issue--sometimes the SP drops<br>
>dual-protocol support. Sometimes, I release a special attribute with<br>
>only one encoding. I would like a more permanent solution, either in the<br>
>form of good configuration directives, or just better standardization.<br>
<br>
</div>We did standardize it, you're not following the profile, that's all.<br>
<div class=""><br>
>1) Is it wrong to have two encoders on an attribute?<br>
<br>
</div>Not in all cases, but it's a bad thing to attach a non-existent name that<br>
is actually a name for an attribute in another SAML version. Those names<br>
simply don't exist for both SAML versions.<br>
<div class=""><br>
> It serves the purpose we had of matching the name no matter which<br>
>scheme the SP chose.<br>
> And it didn't seem to me that URN:MACE or OID formats were specific to<br>
>a particular protocol--they are just two different names for the same<br>
>thing.<br>
<br>
</div>That is definitely untrue, so that's a misunderstanding.<br>
<div class=""><br>
> But it certainly hasn't worked out as cleanly as I was hoping it would.<br>
> I think that's largely because the default examples is to use OID for<br>
>SAML2 and URN for SAML1 and that has become the defacto standard.<br>
<br>
</div>Those aren't purely examples, they are defaults derived from the I2MI<br>
attribute profile for eduPerson that Shibboleth adopted. The SAML 2 names<br>
come from the SAML 2 standard, so are de jure, not de facto. The SAML 1<br>
names were assigned by MACE-Dir as part of the original pre-SAML2 profile,<br>
and since several of them were invented by MACE-Dir, it was up to MACE-Dir<br>
to assign the SAML names, so that again is de jure. The de facto cases<br>
were the legacy LDAP attributes that weren't defined by eduPerson. We took<br>
a wrong turn in naming them, and that's purely profile convention. But it<br>
is well-defined.<br>
<div class=""><br>
>What would really make my life simpler is an improvement to the SP code<br>
>that took the attributes and when it saw "12345;12345" just returned<br>
>"12345". The classic array dupe reduction. But I'm not looking for an<br>
>improvement to Shibboleth to solve my issue.<br>
<br>
</div>Suffice to say this is not so easy due to a variety of things the SP is<br>
doing with aliasing names, and would have to be done so late that it adds<br>
cycles to every HTTP request. I've considered having an option to do so as<br>
a just in time step, but it would be off by default. Or the SP will<br>
eventually just not support aliasing, and that will make it more practical<br>
to do this.<br>
<div class=""><br>
>In the end, if there's not a simple fix my larger scale resolution will<br>
>be to split the encodings into two separate attributes on the IDP side<br>
>and release the right ones at the right time, but that's confusing to<br>
>maintain.<br>
<br>
</div>As Peter said, the defaults already have examples of all the right<br>
encodings. There's nothing to maintain. If you see a MACE name, it's SAML<br>
1, period. If you don't see one, or ar adding something new, use an OID if<br>
it's an LDAP attribute. That's pretty much it. The only use case for<br>
duplicate encodings is to support something that's not a standard, and<br>
usually that's better done with a second attribute definition and a<br>
dedicated encoding, and then just releasing that attribute.<br>
<span class="HOEnZb"><font color="#888888"><br>
-- Scott<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
--<br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net">users-unsubscribe@shibboleth.net</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr">
<font face="arial black, sans-serif">Chris Peters</font><br>Middleware Services Developer<br>Office of Information Technology - NSP<br>(949) 824-6845<br><a href="mailto:cjpeters@uci.edu" target="_blank">cjpeters@uci.edu</a><br>
</div>
</div>