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."
