SP-specific failure to generate 'good' SAML assertion

[David Bantz]

Thank you Peter, Scott and Kevin.

The SAML authentication request does refer to a NameID as you suggest.

14:20:38.500 - DEBUG [PROTOCOL_MESSAGE:113] -
<?xml version="1.0" encoding="UTF-8"?><ns0:AuthnRequest xmlns:ns0="urn:oasis:names:tc:SAML:2.0:protocol" AssertionConsumerServiceURL="https://www.fuzemeeting.com/fuze/saml_verify/alaskaedu" Destination="https://idp.alaska.edu/idp/profile/SAML2/Redirect/SSO" ID="id-f6ea64e95fbae2638f2c975fa6b29809" IssueInstant="2013-11-12T23:20:38Z" ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" ProviderName="Test FB SAML" Version="2.0" xmlns:ns1="urn:oasis:names:tc:SAML:2.0:assertion">
   <ns1:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">www.fuzemeeting.com</ns1:Issuer>
   <ns0:NameIDPolicy AllowCreate="true" Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"/>
</ns0:AuthnRequest>

And while I remembered that we released transientId to anyone, upon closer
examination I see that portion of the release policy was commented out as
part of the attempt to integrate with GAE.

So I added an explicit release of transientId, which seems to have the appropriate
encoder:

attribute-resolver.xml fragment:

    <resolver:AttributeDefinition id="transientId" xsi:type="TransientId" xmlns="urn:mace:shibboleth:2.0:resolver:ad">
        <resolver:AttributeEncoder xsi:type="SAML1StringNameIdentifier" xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
            nameFormat="urn:mace:shibboleth:1.0:nameIdentifier" />

        <resolver:AttributeEncoder xsi:type="SAML2StringNameID" xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
            nameFormat="urn:oasis:names:tc:SAML:2.0:nameid-format:transient" />

    </resolver:AttributeDefinition>

While a value of transientId is created and among those filtered for release to the appropriate end point,
it is not included in the SAML assertion, with the following debug message:

idp-process.log fragment:

14:20:48.628 - DEBUG [edu.internet2.middleware.shibboleth.common.attribute.filtering.provider.ShibbolethAttributeFilteringEngine:114] - Filtered attributes for principal dabantz.  The following attributes remain: [surname, transientId, email, eduPersonPrincipalName, givenName]
14:20:48.628 - DEBUG [edu.internet2.middleware.shibboleth.idp.profile.saml2.AbstractSAML2ProfileHandler:501] - Creating attribute statement in response to SAML request 'id-f6ea64e95fbae2638f2c975fa6b29809' from relying party 'www.fuzemeeting.com'
14:20:48.628 - DEBUG [edu.internet2.middleware.shibboleth.common.attribute.provider.ShibbolethSAML2AttributeAuthority:215] - Encoded attribute surname with encoder of type edu.internet2.middleware.shibboleth.common.attribute.encoding.provider.SAML2StringAttributeEncoder
14:20:48.628 - DEBUG [edu.internet2.middleware.shibboleth.common.attribute.provider.ShibbolethSAML2AttributeAuthority:226] - Attribute transientId was not encoded because no SAML2AttributeEncoder was attached to it.
14:20:48.629 - DEBUG [edu.internet2.middleware.shibboleth.common.attribute.provider.ShibbolethSAML2AttributeAuthority:215] - Encoded attribute email with encoder of type edu.internet2.middleware.shibboleth.common.attribute.encoding.provider.SAML2StringAttributeEncoder

What is the incompatibility between my resolver definition and the attribute encoder?

On Tue, 12 Nov 2013, at 11:29 , Peter Schober <peter.schober at univie.ac.at> wrote:

> * David Bantz <dabantz at alaska.edu> [2013-11-12 21:10]:
>> I see the warning that no attribute can be encoded as NameIdentifier
>> in “required” format; “good” responses to other SPs have messages
>> that no attribute can be encoded as NameIdentifier in “supported”
>> format (not labeled warning).
>> I suspect this should tell me something useful, but admit I don’t
>> understand what it’s telling me.
> 
> Have a look at the authentication request, which should also be in the
> DEBUG log (or grab a new one frmo the browser, easiest with Firefox's
> SAML tracer extension). Seems the SP requests a NameID of format
> "urn:oasis:names:tc:SAML:2.0:nameid-format:transient"
> (which btw does not make too much sense, cf. a very recent thread
> about that).
> 
>> <saml2p:StatusMessage>Required NameID format not supported</saml2p:StatusMessage>
> 
> Did you block release of the default attribute "transientId" in your
> filter (or change the resolver wrt that)? Even a newly installed IDP
> will be able to supply NameIDs of that format so you must have
> changed/disabled that.
> -peter
> 
> 
> --
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20131112/e5e5d6cc/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: Message signed with OpenPGP using GPGMail
Url : http://shibboleth.net/pipermail/users/attachments/20131112/e5e5d6cc/attachment-0001.bin