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."
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."
Hey everyone,
This isn't a "how does it work" question but rather "it's broke and I
don't know why". Please let me know if this is off-topic here.
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. In the logs, I see the following:
[Thu Feb 22 16:47:49.219942 2018] [wsgi:error] [pid 9824] [remote ...]
[2018-02-22 16:47:49,219] [DEBUG] [satosa.proxy_server]: unpack_post::
{'RelayState': '...', 'SAMLResponse': '...'
[Thu Feb 22 16:47:49.231630 2018] [wsgi:error] [pid 9824] [remote ...]
[2018-02-22 16:47:49,231] [DEBUG] [satosa.state]:
[urn:uuid:3bb9c05d-b665-4c23-9a89-8affc05d4574] Loading state from
cookie: SATOSA_STATE='...'; ...
[Thu Feb 22 16:47:49.231816 2018] [wsgi:error] [pid 9824] [remote
10.63.1.38:51166] [2018-02-22 16:47:49,231] [DEBUG] [satosa.routing]:
[urn:uuid:3bb9c05d-b665-4c23-9a89-8affc05d4574] Routing path:
Saml2/acs/post
What am I missing? How do I go about troubleshooting this further?
Best wishes,
Matthew
--
"The lyf so short, the craft so longe to lerne."
Oh, sorry my reply only went to Janusz.
But while letting all you others also see my answer I’d like to add that I’d like to
rewrite the OIDC frontend to SATOSA.
It’s now base on pyOP which not readily extensible.
I’d rather use the pyoidc next generation now being worked on
(you can find it as oicmsg, oiccli and oicrp on https://github.com/identitypython)
If we where to switch to nextgen, adding support for PKCE to SATOSA would just be
configuration.
There are still some work needed on nextgen, so no change in the near future.
> Begin forwarded message:
>
> From: Roland Hedberg <roland at catalogix.se>
> Subject: Re: [satosa-users] PKCE support
> Date: 1 December 2017 at 19:51:29 CET
> To: Janusz Ulanowski <janusz.ulanowski at heanet.ie>
>
>
>
>> On 1 Dec 2017, at 15:59, Janusz Ulanowski <janusz.ulanowski at heanet.ie> wrote:
>>
>> Hi,
>> Just curious. Will be PKCE supported in oidc-frontend?
>
> If it’s not there right now it will be added.
> pyoidc has support for it so it should not be that hard.
>
> — Roland
>
