Dear all,
Scott Koranda fixed this problem in the following pysaml2 pull request:
https://github.com/IdentityPython/pysaml2/pull/502
Thank you, Scott!
Best wishes,
Matthew
--
"The lyf so short, the craft so longe to lerne."
Niels writes:
> I think you need to set the name id format in the frontend config like
> so:
I tested this and unfortunately, it doesn't work. On further inspection this SP includes in its AuthnRequest a NameIDPolicy element with a format of "urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified". This overrides the NameIDFormat I specified in the SP's metadata. It also overrides the IdP configuration setting you told me to change. I've opened a ticket with the vendor, asking them to conform to SAML2int (which recommends omitting the NameIDPolicy element entirely), but it's unlikely that will change anything.
Best wishes,
Matthew
--
"The lyf so short, the craft so longe to lerne."
Hello again,
We have a SP that sends a SAMLRequest without a RelayState. SATOSA's
SAMLResponse includes a RelayState of "None". This causes the SP to
redirect the user to a non-existent URL.
Is this a bug in SATOSA, for blindly serializing a Python None value?
Or is this a bug in the SP, for not including a valid RelayState value
with its SAMLRequest?
Best wishes,
Matthew
--
"The lyf so short, the craft so longe to lerne."
Dear all,
How do I force SATOSA to issue a persistent NameID for a given SP? The
SP's metadata includes the relevant NameIDFormat element inside the
SPSSODescriptor element:
https://gist.github.com/xenophonf/bc802a33a2e9caa2457e355c5b9d1651
However, SATOSA still issues a transient NameID in its SAML
AuthnResponse. What's especially frustrating is that I have this
working for another SP, so I'm not sure what I'm missing beyond the
NameIDFormat in the SP metadata.
Best wishes,
Matthew
--
"The lyf so short, the craft so longe to lerne."
Dear all,
Is it possible to use a different discovery service depending on the SP
that sent a SAML AuthnRequest to SATOSA, or do I have to do that in the
discovery service's frontend somehow?
Best wishes,
Matthew
--
"The lyf so short, the craft so longe to lerne."
So here's the next question, related to passing unmodified assertions from SATOSA to a SP, specifically COmanage and Shibboleth: What's the right way to bypass the scope checks Shibboleth usually performs on ePPN/ePTID/ePUID? I'm using the following PrimaryIdentifier configuration:
```yaml
module: primary_identifier.PrimaryIdentifier
name: PrimaryIdentifier
config:
## look for identifiers in this order (first match wins)
ordered_identifier_candidates:
- attribute_names:
- epuid
- attribute_names:
- eppn
- name_id
name_id_format: urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
- attribute_names:
- eppn
- edupersontargetedid
- attribute_names:
- eppn
- add_scope: issuer_entityid
attribute_names:
- name_id
name_id_format: urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
- add_scope: issuer_entityid
attribute_names:
- edupersontargetedid
primary_identifier:
"uid"
clear_input_attributes:
false
```
Best wishes,
Matthew
--
"The lyf so short, the craft so longe to lerne."
> So here's the next question, related to passing unmodified assertions
> from SATOSA to a SP, specifically COmanage and Shibboleth: What's the
> right way to bypass the scope checks Shibboleth usually performs on
> ePPN/ePTID/ePUID?
I'd like to add that I tried the following:
- removed the Scope element from the SATOSA IdP metadata
- changed the attribute mappings in Shibboleth to use StringAttributeDecoder instead of ScopedAttributeDecoder
- both of the above together
Shibboleth logs the following:
```
2018-04-09 21:14:07 WARN Shibboleth.AttributeFilter [2]: removed value at position (0) of attribute (eppn) from (https://proxy-auth.example.com/satosa)
2018-04-09 21:14:07 WARN Shibboleth.AttributeFilter [2]: no values left, removing attribute (eppn) from (https://proxy-auth.example.com/satosa)
```
Best wishes,
Matthew
--
"The lyf so short, the craft so longe to lerne."
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."
