Dealing with Compounded Attributes

[Christopher Peters]

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.

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.

Again, thanks.

Chris


On Tue, Jun 24, 2014 at 9:47 AM, Cantor, Scott <cantor.2 at osu.edu> wrote:

> On 6/24/14, 12:19 PM, "Christopher Peters" <cjpeters at uci.edu> wrote:
>
> >Last year, we made the somewhat unwise decision to add encodings to
> >attributes to support both the URN:MACE and OID namespaces.  That is to
> >say, for all our core attributes each AttributeDefinition has two
> >encoders per protocol.  e.g.
>
> There are no urn:mace names for attributes in SAML 2. Not one that I can
> think of offhand.
>
> >So far, we have been working around the issue--sometimes the SP drops
> >dual-protocol support.  Sometimes, I release a special attribute with
> >only one encoding.  I would like a more permanent solution, either in the
> >form of good configuration directives, or just better standardization.
>
> We did standardize it, you're not following the profile, that's all.
>
> >1)  Is it wrong to have two encoders on an attribute?
>
> Not in all cases, but it's a bad thing to attach a non-existent name that
> is actually a name for an attribute in another SAML version. Those names
> simply don't exist for both SAML versions.
>
> >  It serves the purpose we had of matching the name no matter which
> >scheme the SP chose.
> >  And it didn't seem to me that URN:MACE or OID formats were specific to
> >a particular protocol--they are just two different names for the same
> >thing.
>
> That is definitely untrue, so that's a misunderstanding.
>
> >  But it certainly hasn't worked out as cleanly as I was hoping it would.
> > I think that's largely because the default examples is to use OID for
> >SAML2 and URN for SAML1 and that has become the defacto standard.
>
> Those aren't purely examples, they are defaults derived from the I2MI
> attribute profile for eduPerson that Shibboleth adopted. The SAML 2 names
> come from the SAML 2 standard, so are de jure, not de facto. The SAML 1
> names were assigned by MACE-Dir as part of the original pre-SAML2 profile,
> and since several of them were invented by MACE-Dir, it was up to MACE-Dir
> to assign the SAML names, so that again is de jure. The de facto cases
> were the legacy LDAP attributes that weren't defined by eduPerson. We took
> a wrong turn in naming them, and that's purely profile convention. But it
> is well-defined.
>
> >What would really make my life simpler is an improvement to the SP code
> >that took the attributes and when it saw "12345;12345" just returned
> >"12345".  The classic array dupe reduction.  But I'm not looking for an
> >improvement to Shibboleth to solve my issue.
>
> Suffice to say this is not so easy due to a variety of things the SP is
> doing with aliasing names, and would have to be done so late that it adds
> cycles to every HTTP request. I've considered having an option to do so as
> a just in time step, but it would be off by default. Or the SP will
> eventually just not support aliasing, and that will make it more practical
> to do this.
>
> >In the end, if there's not a simple fix my larger scale resolution will
> >be to split the encodings into two separate attributes on the IDP side
> >and release the right ones at the right time, but that's confusing to
> >maintain.
>
> As Peter said, the defaults already have examples of all the right
> encodings. There's nothing to maintain. If you see a MACE name, it's SAML
> 1, period. If you don't see one, or ar adding something new, use an OID if
> it's an LDAP attribute. That's pretty much it. The only use case for
> duplicate encodings is to support something that's not a standard, and
> usually that's better done with a second attribute definition and a
> dedicated encoding, and then just releasing that attribute.
>
> -- Scott
>
>
> --
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>



-- 
Chris Peters
Middleware Services Developer
Office of Information Technology - NSP
(949) 824-6845
cjpeters at uci.edu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20140624/bbb75eaf/attachment-0001.html