Hi all,
I want to include a KeyDescriptor for use=encryption in the generated
SAML2 metadata. I'm talking about the
{host}/Saml2/proxy_saml2_backend.xml endpoint.
The following config works (i.e. SATOSA happily accepts encrypted
assertions), however the metadata endpoint does *not* include
use="encryption":
sp_config:
key_file: /etc/satosa/credentials/saml2backend.key
cert_file: /etc/satosa/credentials/saml2backend.crt
On the other hand, the following config does not work (i.e. SATOSA
throws an exception, once an encrypted assertion is received), however
the metadata endpoint *does* include use="encryption":
sp_config:
key_file: /etc/satosa/credentials/saml2backend.key
cert_file: /etc/satosa/credentials/saml2backend.crt
encryption_keypairs:
- key_file: /etc/satosa/credentials/saml2backend.key
cert_file: /etc/satosa/credentials/saml2backend.crt
I'm sure there's an easy solution. Anyone able to help?
Cheers,
David
I am trying to put this proxy solution in place in order to provide support for the REFEDs MFA profile. Here is what I want to implement:
1. SP sends Auth Req to Satosa front end with REFEDs MFA profile ACR
2. Satosa makes a routing decision based on existence (or not) of the MFA profile in the request
3. If MFA profile exists, forward requests to IDP 1. Otherwise, route to IDP 2.
4a. Routing to IDP 1 for MFA makes an assumption that MFA was performed and then inserts the MFA profile into the returned SAML response
4b. Routing to IDP 2 for non-MFA makes an assumption that MFA was NOT performed and does not modify the response
5. The Satosa front end returns the assertion to the SAML SP
I'd like this routing to be dynamic based only on the existence of the MFA profile in the request without having to maintain a static mapping of SP entity IDs.
Reviewing the code, it seems like this might be possible in the DecideBackendByRequester micro service, however the functionality there is based on a static lookup table of entity IDs.
A dynamic routing might be possible with a similar approach if one is able to obtain the ACR from the request context decorators. Is the ACR information added to the request decorator (internal_data) when the inbound request is processed?
Does this seem like a reasonable approach to the problem?
Thanks,
Jim
Hello,
I’m hitting a strange problem; when a successful SAML response is received by the Satosa backend containing a pretty complete attribute statement (see below), the attributes not recognised by the Backend and I see the error “backend received attributes: {}”.
I’m currently just testing things and haven’t changed the internal_attributes.yaml from the example. My IdP is currently just the SimpleSAMLphp userpass example with some mocked up SAML attributes. I wondered whether the attribute Name Format is incorrect, but I don’t see where this can be configured within Satosa.
Has anyone else hit this problem?
Thanks in advance,
Hannah
====================
<saml:AttributeStatement>
<saml:Attribute Name="uid"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
<saml:AttributeValue xsi:type="xs:string">student</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute Name="eduPersonAffiliation"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
<saml:AttributeValue xsi:type="xs:string">member</saml:AttributeValue>
<saml:AttributeValue xsi:type="xs:string">student</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute Name="eduPersonTargetedID"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
<saml:AttributeValue xsi:type="xs:string">123456789</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute Name="givenName"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
<saml:AttributeValue xsi:type="xs:string">Test</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute Name="displayName"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
<saml:AttributeValue xsi:type="xs:string">Test Person</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute Name="email"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
<saml:AttributeValue xsi:type="xs:string">test at cern.ch</saml:AttributeValue>
</saml:Attribute>
</saml:AttributeStatement>
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."
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."
