An open discussion list for topics related to the eduGAIN interfederation service.

[Peter Schober <peter.schober AT univie.ac.at>]

Hi Pavel,

* Pavel Šipoš <pavel.sipos AT arnes.si> [2018-05-16 10:32]:
> Eduroam CAT expects urn:oid:1.3.6.1.4.1.5923.1.1.1.10 to be in XML
> form.

That's also the only allowed content for an attribute of that name,
for SAML1:

  "If the AttributeName attribute of the <saml:Attribute> element has
  value urn:oid:1.3.6.1.4.1.5923.1.1.1.10 then the <saml:AttributeValue>
  element's content MUST be a <saml2:NameID> element with a Format XML
  attribute of urn:oasis:names:tc:SAML:2.0:nameid-format:persistent as
  described in section 8.3.7 of [SAML2Core]."

as well as for SAML2:

  "The <saml2:AttributeValue> element's content MUST be a
  <saml2:NameID> element with a Format XML attribute of
  urn:oasis:names:tc:SAML:2.0:nameid-format:persistent as described in
  section 8.3.7 of [SAML2Core]."

as per the MACE-Dir SAML Attribute Profiles,
http://macedir.org/docs/internet2-mace-dir-saml-attributes-latest.pdf

> Currently our IdP sends deprecated string form:
> 
> <saml:Attribute Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.10"
>   NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
>   
> <saml:AttributeValue>629d9939123cddb4444372sssba2c6e8a6fb0963</saml:AttributeValue>
> </saml:Attribute>

As per above that's not deprecated, it's outright illegal -- and has
been for at least 10 years (!) when the above SAML Profile was last
updated.

And it would still be illegal even if:
 * the protocol were SAML1, AND
 * the attribute name were "urn:mace:dir:attribute-def:eduPersonTargetedID"
because then it'd be missing the madatory "Scope" XML-attribute.

So basically it's invalid no matter what, and no matter when. ;)

> The problem is that most of SP in our ArnesAAI federation expect
> deprecated form of eptid.

They're all depending on invalid/broken data, then.

Your best bet is probably getting all of those SPs to move to the new
(not yet published) SAML V2.0 Subject Identifier Attributes,
https://wiki.oasis-open.org/security/SAMLSubjectIDAttr
and replace *all* uses of NameIDs (other than transient) with those.

At least then you'll have to make that transition only once, to get
rid of NameIDs wholesale, instead of fixing all IDPs and SPs in your
federation to rely on the correct form of the attribute, and *then*
get rid of it later anyway.

> Is it somehow possible to make exceptions to know which form to
> serve based on SP entityId? What is best way to handle these cases?

I guess anything is possible with SimpleSAMLphp ;) as you can run your
own PHP code in authproc filters, in metadata and the like.
Unless someone has suggestions here I'd ask this on the SimpleSAMLphp
users mailing list, though.

> Do you have any suggestions how to redefine attribute-map at Shibboleth SP
> to map received saml:NameID value as eduPersonTargetedID?

You're not sending a saml:NameID so that's not what the map would contain:
You're sending an unscoped, simple/flat string as an attribute value,
without any qualfiers or scopes. (I.e., it's missing 2 out of the 3
constituent parts of a persistent NameID.)

Since what you're sending neither is a NameID nor scoped the simplest
possible entry to the SP's attribute-map.xml would apply to this
pathological form:

  <Attribute name="urn:oid:1.3.6.1.4.1.5923.1.1.1.10" id="your-desired-name">

And while you can map that to whatever you like (as the result of the
Shib SP's attribute map is a variable name internal to the server it's
running on) I would NOT map it to the same internal attribute as real
persistent NameIDs or correct eduPersonTargetedID attributes, as what
you have here is NOT a persistent NameID: It's missing at least the
NameQualifier (or Scope) that uniquly qualifies the value with the
entityID of the issuing IDP.
And any use of that pathological variant would have to be fixed up
before further use within the application, either in Shibboleth SP
config[1] or in your own application code.
Such fixing is much easier if you map the correct form and the
pathologocal form to two different internal IDs (if that's even
possible), so you can only trigger the fixing transform/code for the
incorrect ones.

And unless the application is already relying on REMOTE_USER for such
identifiers (in which case you could simply use the Shib SP's
REMOTE_USER precedence list, adding the correct and the
fixed-up-incorrect internal attribute names to that list) you'd then
have to iterate over the different attribute names in your application
code so you could use either form transparently within the application.

HTH,
-peter

[1] 
https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPAttributeResolver#NativeSPAttributeResolver-TransformAttributeResolver(Version2.5andAbove)