AVA Hash empty even though attributes are present in response
See original GitHub issueHello! I’m implementing SAML login using djangsaml2 into our Askbot application but I’m running into a problem with the attribute hash being empty, even though there are attributes in the response.
Our IdP is a FortiAuthenticator and you specify which attributes are included in the acs request. I have specified to include the username and email address.
After I authenticate with the IdP, I’m redirected back to a URL managed by djangosaml2, which parses the SAML response and then attempts to authenticate the user. This is failing, because it doesn’t have enough information to create a user object.
Here is the SAML response (omitted some objects)
<samlp:Response Destination="http://my-sp-url/saml/acs/"
ID="_130c45a1cd2c4b16b7677dee751abd6d" InResponseTo="id-MNj4X055Hy0ZsNkOu"
IssueInstant="2017-02-21T18:25:13Z" Version="2.0" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
<saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">http://my-idp-url/saml-idp/30ylzqaj7wn2s69a/metadata/</saml:Issuer>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"></ds:CanonicalizationMethod>
<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"></ds:SignatureMethod>
<ds:Reference URI="#_130c45a1cd2c4b16b7677dee751abd6d">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"></ds:Transform>
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"></ds:Transform>
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"></ds:DigestMethod>
<ds:DigestValue>omitted</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>omitted</ds:SignatureValue>
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>omitted</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</ds:Signature>
<samlp:Status>
<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"></samlp:StatusCode>
</samlp:Status>
<saml:Assertion ID="_d7c7e26813f74f688e2ca4a358266764" IssueInstant="2017-02-21T18:25:13Z"
Version="2.0" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
<saml:Issuer>http://my-idp-url/saml-idp/30ylzqaj7wn2s69a/metadata/</saml:Issuer>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"></ds:CanonicalizationMethod>
<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"></ds:SignatureMethod>
<ds:Reference URI="#_d7c7e26813f74f688e2ca4a358266764">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"></ds:Transform>
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"></ds:Transform>
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"></ds:DigestMethod>
<ds:DigestValue>omitted</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>omitted</ds:SignatureValue>
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>omitted</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</ds:Signature>
<saml:Subject>
<saml:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:unspecified"
SPNameQualifier="http://my-sp-url/saml/metadata/">My Username Here</saml:NameID>
<saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<saml:SubjectConfirmationData InResponseTo="id-MNj4X055Hy0ZsNkOu"
NotOnOrAfter="2017-02-21T18:40:13Z" Recipient="http://my-sp-url/saml/acs/"></saml:SubjectConfirmationData>
</saml:SubjectConfirmation>
</saml:Subject>
<saml:Conditions NotBefore="2017-02-21T18:10:13Z" NotOnOrAfter="2017-02-21T18:40:13Z">
<saml:AudienceRestriction>
<saml:Audience>http://my-sp-url/saml/metadata/</saml:Audience>
</saml:AudienceRestriction>
</saml:Conditions>
<saml:AuthnStatement AuthnInstant="2017-02-21T18:25:13Z">
<saml:AuthnContext>
<saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</saml:AuthnContextClassRef>
</saml:AuthnContext>
</saml:AuthnStatement>
<saml:AttributeStatement>
<saml:Attribute Name="username">
<saml:AttributeValue>My Username Here</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute Name="mail">
<saml:AttributeValue>My Email Here</saml:AttributeValue>
</saml:Attribute>
</saml:AttributeStatement>
</saml:Assertion>
</samlp:Response>
As you can see near the end of the response, the username and mail attribute are provided.
However, the output from pysaml2 is:
***Unencrypted assertion***
signed
('assertion context: %s', 'AuthnReq')
('assertion keys: %s', ['authn_statement', 'attribute_statement', 'issue_instant', 'version', 'signature', 'subject', 'conditions', 'id', 'issuer'])
('outstanding_queries: %s', {'id-MNj4X055Hy0ZsNkOu': u'/'})
('conditions: %s', <saml2.saml.Conditions object at 0x7ff4cb456250>)
--- Getting Identity ---
('Subject NameID: %s', <saml2.saml.NameID object at 0x7ff4cb4562d0>)
('Attribute Statement: %s', <saml2.saml.AttributeStatement object at 0x7ff4cb456390>)
('Converts name format: %s', 'urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified')
('Converts name format: %s', 'urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified')
('Converts name format: %s', 'urn:oasis:names:tc:SAML:2.0:attrname-format:basic')
('Converts name format: %s', 'urn:oasis:names:tc:SAML:2.0:attrname-format:uri')
('Converts name format: %s', 'urn:mace:shibboleth:1.0:attributeNamespace:uri')
Missing Attribute Statement
('--- AVA: %s', {})
Issue Analytics
- State:
- Created 7 years ago
- Comments:5 (4 by maintainers)

Top Related StackOverflow Question
Hi @jkakavas
It’s been some time since I reported this issue, so I’m just going to summarize what I had to do for the people coming from Google.
The attributes were defined in the mapping, but the problem I found was that becasue this is an “unencrypted assertion” (as seen in the output above), PySAML2 considered the attributes “unknown” and ignores them. All of the assertions are over HTTPS, so we felt that SAML-specific encryption was not nessicary (nor did our IdP support it).
What I ended up doing was hard-coding
allow_unknown_attributestoTruein response.py. As soon as I did that, the AVA hash was populated.allow_unknown_attributesis exposed as a configuration option for both the frontend/IdP and backend/SP. The configuration should be on the same level asentityid, ie