Dear all,
I need help understanding why SATOSA isn't passing the IdP assertions
through to an SP. SATOSA sends it a successful authentication response,
but it's devoid of any attributes.
I know that SATOSA gets the right assertion from the IdP because there's
a "backend received attributes" log entry that includes the expected
values.
I see that the PrimaryIdentifier plugin correctly identifies the ePPN
because there's a "PRIMARY_IDENTIFIER: Setting attribute uid" log entry.
I also see the LdapAttributeStore plugin skip processing, as expected.
But when SATOSA routes the request to the Saml2IDP frontend, it logs the
following:
```
Filter: []
returning attributes {}
```
And then the SAML response doesn't include any attributes.
Here's my complete configuration except for passwords and keying
material:
https://gist.github.com/xenophonf/d07ab00a30e5559674936e3a549d0141
What am I missing?
Best wishes,
Matthew
--
"The lyf so short, the craft so longe to lerne."
Hi,
I have a SATOSA use case where the SAML SP that is receiving the
assertion from the SATOSA IdP needs to consume a NameID with format
urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified
with a particular (non-standard) value.
Has anyone done this with SATOSA? If so, my questions are:
1) What is required for the SAML2 frontend configuration?
2) What is required for the metadata of the consuming SP?
3) What do I need to do, say in a microservice, to populate the value?
If the 'unspecified' format is not possible, I might also be able to
leverage the format
urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress
Has anyone used that format for the NameID asserted to the consuming
SP?
Thanks,
Scott
I wrote:
> I have an instance of SATOSA deployed using mod_wsgi. The BASE
> variable in proxy_conf.yaml is set to something like
> `https://federation.example.com/satosa`. Everything works until my
> test IdP returns the SAML authentication response to SATOSA at
> `https://federation.example.com/satosa/Saml2/acs/post`, where it
> returns a 404 error.
SATOSA's URL routing code constructs regular expressions in ways that assume BASE is just a hostname, like this:
https://federation.example.com
Since I want to co-locate SATOSA with COmanage Registry on the same virtual host in this particular deployment, I used WSGIScriptAliasMatch to bypass non-SATOSA URLs:
WSGIScriptAliasMatch ^/(?!(Shibboleth\.sso|registry|img|css|js|favicon.ico|error.html)) /opt/satosa/lib/python3.6/site-packages/satosa/wsgi.py
Best wishes,
Matthew
--
"The lyf so short, the craft so longe to lerne."
