NameID Generation to SP

[Jay Mey]

Hi,

I am new to SAML and Shibboleth in general and I am trying to learn how it works while trying to demo its' flexibility as an IdP. I have an SP which accepts the following NameID Formats:

<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</md:NameIDFormat>
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</md:NameIDFormat>
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</md:NameIDFormat>
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</md:NameIDFormat>

I currently have Shibboleth IdP connecting to Active Directory and returning the correct attributes I need (mail and memberOf). The problem is having the mail attribute encode to the above NameID Formats.

Currently, I have enabled persistent NameID Generator and it seems to be doing the encoding properly as seen below in the idp-process.log. The end result of the mail attribute is a string like "9UoJLXa4TmaVDLUSk+7nh+9xUa4=" which is what is passed on to my SP as the username and email. The SP cannot read it in this format. Is this the correct result that should be expected?

I have read other archived mails related to NameID but I was not able to resolve my issue or to see if I am on the right track here. Any guidance you can provide would be a great help. I have also attached my attribute-resolver and attribute-filter files for reference.

Best Regards,
Jay



2016-03-24 23:37:50,521 - DEBUG [net.shibboleth.idp.saml.saml2.profile.impl.AddAttributeStatementToAssertion:174] - Profile Action AddAttributeStatementToAssertion: Attempting to encode attribute mail as a SAML 2 Attribute

2016-03-24 23:37:50,522 - DEBUG [net.shibboleth.idp.saml.saml2.profile.impl.AddAttributeStatementToAssertion:188] - Profile Action AddAttributeStatementToAssertion: Encoding attribute mail as a SAML 2 Attribute

2016-03-24 23:37:50,523 - DEBUG [net.shibboleth.idp.saml.attribute.encoding.AbstractSAMLAttributeEncoder:154] - Beginning to encode attribute mail

2016-03-24 23:37:50,524 - DEBUG [net.shibboleth.idp.saml.attribute.encoding.SAMLEncoderSupport:73] - Encoding value mickey123 at vmware.com of attribute mail

2016-03-24 23:37:50,525 - DEBUG [net.shibboleth.idp.saml.attribute.encoding.AbstractSAMLAttributeEncoder:191] - Completed encoding 1 values for attribute mail

...

2016-03-24 23:37:50,548 - WARN [org.opensaml.saml.common.profile.logic.MetadataNameIdentifierFormatStrategy:75] - Ignoring NameIDFormat metadata that includes the 'unspecified' format

2016-03-24 23:37:50,549 - DEBUG [net.shibboleth.idp.saml.profile.logic.DefaultNameIdentifierFormatStrategy:100] - Configuration specifies the following formats: [urn:oasis:names:tc:SAML:2.0:nameid-format:persistent, urn:oasis:names:tc:SAML:2.0:nameid-format:transient, urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress, urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified]

2016-03-24 23:37:50,549 - DEBUG [net.shibboleth.idp.saml.profile.logic.DefaultNameIdentifierFormatStrategy:117] - Metadata did not specify any formats, relying on configuration alone

2016-03-24 23:37:50,550 - DEBUG [net.shibboleth.idp.saml.nameid.impl.PersistentSAML2NameIDGenerator:205] - Checking for source attribute mail

2016-03-24 23:37:50,551 - DEBUG [net.shibboleth.idp.saml.nameid.impl.PersistentSAML2NameIDGenerator:225] - Generating persistent NameID from String-valued attribute mail
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20160324/ffd2b32c/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: attribute-filter.xml
Type: application/xml
Size: 1892 bytes
Desc: attribute-filter.xml
URL: <http://shibboleth.net/pipermail/users/attachments/20160324/ffd2b32c/attachment-0002.wsdl>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: attribute-resolver.xml
Type: application/xml
Size: 7840 bytes
Desc: attribute-resolver.xml
URL: <http://shibboleth.net/pipermail/users/attachments/20160324/ffd2b32c/attachment-0003.wsdl>