Support for X509SubjectName Name ID

Ullfig, Roberto Alfredo rullfig at
Thu May 14 14:24:38 UTC 2020

Ok, releasing fixed it. Thanks! Their azure application is still failing - maybe you can give some insight on the matter?

They said something I don't understand and they couldn't clarify:

"We also had to set the Outgoing Claim Type for SAM-Account-Name to "Name Id".  Can you try setting the Outgoing Claim Type to "Name Id"?

and their metadata has this:

<RequestedAttribute Name="SAM-Account-Name" isRequired="true" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic" FriendlyName="Name ID" />

Do you think I'd have to create a new attribute called Name ID? I already created one called SAM-Account-Name and am releasing that.

Roberto Ullfig - rullfig at
Systems Administrator
Enterprise Architecture and Development | ACCC
University of Illinois - Chicago
From: users <users-bounces at> on behalf of Cantor, Scott <cantor.2 at>
Sent: Thursday, May 14, 2020 9:08 AM
To: Shib Users <users at>
Subject: Re: Support for X509SubjectName Name ID

> You have to give it a source of data if you want to use that particular generator, whether it exists already or you have to
> create something new. If you want to use uid, use uid. Either way it has to exist of course.

(and be released to that SP)

If you really want to use unfiltered attributes as a source that's an optional flag you'd have to enable. I wouldn't do that, it's best as a documentation aid if nothing else to release the underlying data to the SP if it's going to be passed through via NameID.

Only the persistent generator really makes much sense to operate on unfiltered data since it's a transform that would not expose the original source.

-- Scott

For Consortium Member technical support, see
To unsubscribe from this list send an email to users-unsubscribe at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the users mailing list