4:02 p.m.
Hi.
I believe I have resolved my issues and have a functioning SATOSA instance in my pre-prod
environment.
I hit 5 main items (so far) and hope that capturing can help others have an easier story.
I’m interested in helping improve docs and need guidance as to where and how – github
wiki? Fork repo then do a pull request?
Reflections on using SATOSA in pre-prod use marching toward full production use so far:
* Starting from zero to this stage was non-small but any other proxy story would have
been more effort IMO.
* These items were costly in time to come by and hope that it helps shorten
implementations to capture them.
* If I had them, SATOSA is a slam dunk on fastest and ‘thinnest’ deployment.
Kudos to the work put into SATOSA and for future work on the horizon.
Thoughts and questions welcome as always .. my notes and details on how I resolved things
are below.
C
Main challenges and steps taken to have SATOSA operating as expected for attribute passing
and assertion handling
=======================================================
1. Sp.xml proved impactful on parsing if it had too much in it thus rendering the
filter attributes empty
===========
I had ACS entries for required/requested attributes which seem to have bumped my
internal_attributes filter sufficiently to zero (empirical observation)
My resolution: remove those elements as well as the MD contact info from the sp.xml
metadata appeared to have resolved this first step
Suggestion: more clarity on this element would help.
1. YAML syntax on how to ingest an aggregate in the ‘backend’ was tough to decipher and
documentation is thin or maybe aged out.
===========
My resulting format working for my docker image: satosa/satosa:latest for the backend.yaml
is:
<snip>
metadata:
remote:
- {url: "https://url.to/fed.xml", cert:
"/opt/satosa/etc/pki/testfed.crt"}
<snip>
This does not align with documentation that I’ve encountered for SATOSA.
Suggestion: configuration for multi-lateral federation would benefit to be an example. As
would version sensitivity of it and more examples to show what would be sufficient to run
1. Internal_attributes.yaml mapping transformed email to mail thus downstream was ‘no
email, no access!’
===========
The mapping of email to mail OIDs – YIKES! Who knew that PKCS_9 +1 vs UCL_DIR_PILOT+3
were different? I hated myself on this one
* The hurt was in internal_attributes.yaml had
* Mail:
* Saml: [email, emailAddress, mail]
* As such it translated the Shib assertion from ‘mail’ to ‘email’ OID
Action taken to resolve: set saml: [mail] for the mail element
Suggestion: there’s a lot to talk about here on mapping – this is a place for some good
practices and what’s there looks good for just working but the transposition was subtle to
detect. Hard to say how to make it easier without more thought.
1. Run SATOSA behind apache to trap errors better was tough to find and used a slightly
different way than the WSGI interface
===========
The reference to error handling is a bit oblique as there’s more than one way to do it and
the WSGI apache proxy was not immediately there for me
Here’s the snippet from the apache2 config that allows me to handle the 404’ing of access
for a more graceful error page handling:
#
# proxy SATOSA so we can handle 404's better
# don’t forget to a2en proxy; a2en proxy_http in apache2
# ProxyErrorOverride is **CRITICAL** to trap the 404 passed up by gunicorn.
Proxypass /Saml2 http://127.0.0.1:8000/Saml2
ProxyPassReverse /Saml2 http://127.0.0.1:8000/Saml2
ProxyErrorOverride On
ErrorDocument 404 /errors/404.html
Suggestion: This is a strong need for error handling. Templating it for the enhancement
listed in the issue tracker not so much as just give me some plain html locations to use
or mount in the container rather than punting to a proxy above resulting in a proxy of a
proxy.
1. To handle ADFS assertions inbound to SATOSA properly needed the
backend.yaml/federation facing settings to want_response_signed=False and not ‘true’
===========
Testing various IdPs like Shibboleth and ADFS revealed that to use ADFS out of the box
with a SAML trust to SATOSA I needed want_response_signed=False.
* This deploys as ‘true’ for SATOSA recommended (and is a good posture to be
fair!) but ADFS won’t play fair with it that I could tell.
* This was only uncovered while reading ‘Signature error: Signature missing for
respose’ in google and found this:
* https://github.com/IdentityPython/pysaml2/issues/490
Suggestion: Again, this is a practitioner configuration. Thankfully the setting is there,
now it needs more revelation in documentation and how to use things and consequences of
the action like this.
From: Chris Phillips <Chris.Phillips at canarie.ca>
Date: Friday, July 19, 2019 at 8:50 AM
To: "satosa-users at lists.sunet.se" <satosa-users at lists.sunet.se>
Subject: Guidance sought on allowing attributes to pass through with
statosa/statosa:latest
Hi.
I’m trying to work through a SATOSA story of SP with only one IdP configured to be proxied
to use a federation aggregates’ metadata. Sign on is working and always get Filter: [] and
returning attributes {} when I expect attributes to be sent by SATOSA.
I’m using the docker image Latest and have also tried v4.4.0 with same result. I don’t
think I’m too fancy and am using SATOSA ‘out of the box’ and am looking for
guidance/insight/suggestions on what may be wrong, missing, or off by a few columns in
YAML 😊
I have had success in the past at TIIME in Feb2019 with Matt E. but that was non-docker
and a v3.4.8 install:
https://lists.sunet.se/pipermail/satosa-users/2019-February/000067.html
I have seen/explored the microservices/ filter_attributes.yaml.example but that is more
along suppression rather than permit passage. Must I whitelist everything?
Thanks for any insight/guidance on this. I have a gist with front/backends here:
https://gist.github.com/canariecaf/2216d3de5e5872ecaa08cf03548ec559
Happy to jump on Slack and chat there too – is there a slack area for satosa/idpy BTW or
the edugain.slack.com location have idpy like venues for chats like this?
C
satosa_1 | [2019-07-19 02:21:07] [DEBUG]: [urn:uuid:d7919f3e-0361-4ec5-aa1b-b5560eb6305c]
Routing path: Saml2/acs/post
satosa_1 | [2019-07-19 02:21:07] [DEBUG]: [urn:uuid:d7919f3e-0361-4ec5-aa1b-b5560eb6305c]
Found registered endpoint: module name:'Saml2', endpoint: Saml2/acs/post
satosa_1 | [2019-07-19 02:21:07] [DEBUG]: backend attribute '['email',
'emailAdress', 'mail']' mapped to mail
satosa_1 | [2019-07-19 02:21:07] [DEBUG]: skipped backend attribute
'['postaladdress']': no value found
satosa_1 | [2019-07-19 02:21:07] [DEBUG]: skipped backend attribute '['sn',
'surname']': no value found
satosa_1 | [2019-07-19 02:21:07] [DEBUG]: backend attribute
'['displayName']' mapped to displayname
satosa_1 | [2019-07-19 02:21:07] [DEBUG]: skipped backend attribute
'['givenName']': no value found
satosa_1 | [2019-07-19 02:21:07] [DEBUG]: backend attribute
'['eduPersonTargetedID']' mapped to edupersontargetedid
satosa_1 | [2019-07-19 02:21:07] [DEBUG]: skipped backend attribute
'['cn']': no value found
satosa_1 | [2019-07-19 02:21:07] [DEBUG]: [urn:uuid:d7919f3e-0361-4ec5-aa1b-b5560eb6305c]
backend received attributes:
satosa_1 | {
satosa_1 | "eduPersonPrincipalName": [
satosa_1 | "something at canarie.ca"
satosa_1 | ],
satosa_1 | "mail": [
satosa_1 | "Chris.Phillips at canarie.ca"
satosa_1 | ],
satosa_1 | "eduPersonScopedAffiliation": [
satosa_1 | "staff at canarie.ca"
satosa_1 | ],
satosa_1 | "eduPersonAffiliation": [
satosa_1 | "staff"
satosa_1 | ],
satosa_1 | "eduPersonTargetedID": [
satosa_1 | "SUPPRESED="
satosa_1 | ],
satosa_1 | "displayName": [
satosa_1 | "Chris Phillips"
satosa_1 | ]
satosa_1 | }
satosa_1 | [2019-07-19 02:21:07] [DEBUG]: [urn:uuid:d7919f3e-0361-4ec5-aa1b-b5560eb6305c]
Routing to frontend: Saml2IDP
satosa_1 | [2019-07-19 02:21:07] [DEBUG]: [urn:uuid:d7919f3e-0361-4ec5-aa1b-b5560eb6305c]
Filter: []
satosa_1 | [2019-07-19 02:21:07] [DEBUG]: [urn:uuid:d7919f3e-0361-4ec5-aa1b-b5560eb6305c]
returning attributes {}
satosa_1 | [2019-07-19 02:21:07] [DEBUG]: [urn:uuid:d7919f3e-0361-4ec5-aa1b-b5560eb6305c]
signing with algorithm http://www.w3.org/2001/04/xmldsig-more#rsa-sha256
satosa_1 | [2019-07-19 02:21:07] [DEBUG]: [urn:uuid:d7919f3e-0361-4ec5-aa1b-b5560eb6305c]
using digest algorithm http://www.w3.org/2001/04/xmlenc#sha256
satosa_1 | [2019-07-19 02:21:07] [DEBUG]: [urn:uuid:d7919f3e-0361-4ec5-aa1b-b5560eb6305c]
Saving state as cookie, secure: True, max-age: 1200, path: /
3:43 p.m.
Hi Chris,
I can only share my experience, as non-docker user.
https://github.com/peppelinux/Satosa-saml2saml
in that example directory you'll find my custom, base, configuration.
You'll also find a quite original attribute mapping, because we use proxy
also for SPID italian federation, so I needed to handle an hybrid
configuration for attr name format BASIC and URI. Devastating.
I use nginx and you'll find in example/uwsgi_setup my standard base
configuration with log rotation and tcp server tuning, as you can see I do
not use gunicorn.
I also use my satosa fork, in pplnx-dev branch, where I have my PR already
merged but I suggest you to use the official SATOSA master branch because I
think that those PR will be merge soon as possibile.
Signature missing in pysaml appears when the config were loaded, each time
an AuthnRequest come up.
In pysaml2 config the entityID of the requester is matched in config's
MetadataStore, if it's not there Signature missing will throw. I think you
should have just to investigate in metadata presence and validity.
I also use pyff to getch metadatas and I serve them through MDQ but via
httpd static file serve:
https://github.com/IdentityPython/pyFF/issues/172
Nginx takes 36ms to give us metadatas, python and any other CGI cannot do
better then this!
Hope to hear you soon
Il giorno ven 26 lug 2019 alle ore 18:02 Chris Phillips <
Chris.Phillips at canarie.ca> ha scritto:
Hi.
I believe I have resolved my issues and have a functioning SATOSA instance
in my pre-prod environment.
I hit 5 main items (so far) and hope that capturing can help others have
an easier story.
I’m interested in helping improve docs and need guidance as to where and
how – github wiki? Fork repo then do a pull request?
Reflections on using SATOSA in pre-prod use marching toward full
production use so far:
- Starting from zero to this stage was non-small but any other proxy
story would have been more effort IMO.
- These items were costly in time to come by and hope that it helps
shorten implementations to capture them.
- If I had them, SATOSA is a slam dunk on fastest and ‘thinnest’
deployment.
Kudos to the work put into SATOSA and for future work on the horizon.
Thoughts and questions welcome as always .. my notes and details on how I
resolved things are below.
C
Main challenges and steps taken to have SATOSA operating as expected for
attribute passing and assertion handling
=======================================================
1. Sp.xml proved impactful on parsing if it had too much in it thus
rendering the filter attributes empty
===========
I had ACS entries for required/requested attributes which seem to have
bumped my internal_attributes filter sufficiently to zero (empirical
observation)
My resolution: remove those elements as well as the MD contact info from
the sp.xml metadata appeared to have resolved this first step
Suggestion: more clarity on this element would help.
1. YAML syntax on how to ingest an aggregate in the ‘backend’ was
tough to decipher and documentation is thin or maybe aged out.
===========
My resulting format working for my docker image: satosa/satosa:latest for
the backend.yaml is:
<snip>
metadata:
remote:
- {url: "https://url.to/fed.xml", cert:
"/opt/satosa/etc/pki/testfed.crt"}
<snip>
This does not align with documentation that I’ve encountered for SATOSA.
Suggestion: configuration for multi-lateral federation would benefit to be
an example. As would version sensitivity of it and more examples to show
what would be sufficient to run
1. Internal_attributes.yaml mapping transformed email to mail thus
downstream was ‘no email, no access!’
===========
The mapping of email to mail OIDs – YIKES! Who knew that PKCS_9 +1 vs
UCL_DIR_PILOT+3 were different? I hated myself on this one
- The hurt was in internal_attributes.yaml had
- Mail:
- Saml: [email, emailAddress, mail]
- As such it translated the Shib assertion from ‘mail’ to
‘email’ OID
Action taken to resolve: set saml: [mail] for the mail element
Suggestion: there’s a lot to talk about here on mapping – this is a place
for some good practices and what’s there looks good for just working but
the transposition was subtle to detect. Hard to say how to make it easier
without more thought.
1. Run SATOSA behind apache to trap errors better was tough to find
and used a slightly different way than the WSGI interface
===========
The reference to error handling is a bit oblique as there’s more than one
way to do it and the WSGI apache proxy was not immediately there for me
Here’s the snippet from the apache2 config that allows me to handle the
404’ing of access for a more graceful error page handling:
#
# proxy SATOSA so we can handle 404's better
# don’t forget to a2en proxy; a2en proxy_http in apache2
# ProxyErrorOverride is **CRITICAL** to trap the 404 passed up by gunicorn.
Proxypass /Saml2 http://127.0.0.1:8000/Saml2
ProxyPassReverse /Saml2 http://127.0.0.1:8000/Saml2
ProxyErrorOverride On
ErrorDocument 404 /errors/404.html
Suggestion: This is a strong need for error handling. Templating it for
the enhancement listed in the issue tracker not so much as just give me
some plain html locations to use or mount in the container rather than
punting to a proxy above resulting in a proxy of a proxy.
1. To handle ADFS assertions inbound to SATOSA properly needed the
backend.yaml/federation facing settings to want_response_signed=False and
not ‘true’
===========
Testing various IdPs like Shibboleth and ADFS revealed that to use ADFS
out of the box with a SAML trust to SATOSA I needed
want_response_signed=False.
- This deploys as ‘true’ for SATOSA recommended (and is a good posture
to be fair!) but ADFS won’t play fair with it that I could tell.
- This was only uncovered while reading ‘Signature error: Signature
missing for respose’ in google and found this:
- https://github.com/IdentityPython/pysaml2/issues/490
Suggestion: Again, this is a practitioner configuration. Thankfully the
setting is there, now it needs more revelation in documentation and how to
use things and consequences of the action like this.
*From: *Chris Phillips <Chris.Phillips at canarie.ca>
*Date: *Friday, July 19, 2019 at 8:50 AM
*To: *"satosa-users at lists.sunet.se" <satosa-users at lists.sunet.se>
*Subject: *Guidance sought on allowing attributes to pass through with
statosa/statosa:latest
Hi.
I’m trying to work through a SATOSA story of SP with only one IdP
configured to be proxied to use a federation aggregates’ metadata. Sign on
is working and always get Filter: [] and returning attributes {} when I
expect attributes to be sent by SATOSA.
I’m using the docker image Latest and have also tried v4.4.0 with same
result. I don’t think I’m too fancy and am using SATOSA ‘out of the box’
and am looking for guidance/insight/suggestions on what may be wrong,
missing, or off by a few columns in YAML 😊
I have had success in the past at TIIME in Feb2019 with Matt E. but that
was non-docker and a v3.4.8 install:
https://lists.sunet.se/pipermail/satosa-users/2019-February/000067.html
I have seen/explored the microservices/ filter_attributes.yaml.example
but that is more along suppression rather than permit passage. Must I
whitelist everything?
Thanks for any insight/guidance on this. I have a gist with front/backends
here: https://gist.github.com/canariecaf/2216d3de5e5872ecaa08cf03548ec559
Happy to jump on Slack and chat there too – is there a slack area for
satosa/idpy BTW or the edugain.slack.com location have idpy like venues
for chats like this?
C
satosa_1 | [2019-07-19 02:21:07] [DEBUG]:
[urn:uuid:d7919f3e-0361-4ec5-aa1b-b5560eb6305c] Routing path: Saml2/acs/post
satosa_1 | [2019-07-19 02:21:07] [DEBUG]:
[urn:uuid:d7919f3e-0361-4ec5-aa1b-b5560eb6305c] Found registered endpoint:
module name:'Saml2', endpoint: Saml2/acs/post
satosa_1 | [2019-07-19 02:21:07] [DEBUG]: backend attribute '['email',
'emailAdress', 'mail']' mapped to mail
satosa_1 | [2019-07-19 02:21:07] [DEBUG]: skipped backend attribute
'['postaladdress']': no value found
satosa_1 | [2019-07-19 02:21:07] [DEBUG]: skipped backend attribute
'['sn', 'surname']': no value found
satosa_1 | [2019-07-19 02:21:07] [DEBUG]: backend attribute
'['displayName']' mapped to displayname
satosa_1 | [2019-07-19 02:21:07] [DEBUG]: skipped backend attribute
'['givenName']': no value found
satosa_1 | [2019-07-19 02:21:07] [DEBUG]: backend attribute
'['eduPersonTargetedID']' mapped to edupersontargetedid
satosa_1 | [2019-07-19 02:21:07] [DEBUG]: skipped backend attribute
'['cn']': no value found
satosa_1 | [2019-07-19 02:21:07] [DEBUG]:
[urn:uuid:d7919f3e-0361-4ec5-aa1b-b5560eb6305c] backend received attributes:
satosa_1 | {
satosa_1 | "eduPersonPrincipalName": [
satosa_1 | "something at canarie.ca"
satosa_1 | ],
satosa_1 | "mail": [
satosa_1 | "Chris.Phillips at canarie.ca"
satosa_1 | ],
satosa_1 | "eduPersonScopedAffiliation": [
satosa_1 | "staff at canarie.ca"
satosa_1 | ],
satosa_1 | "eduPersonAffiliation": [
satosa_1 | "staff"
satosa_1 | ],
satosa_1 | "eduPersonTargetedID": [
satosa_1 | "SUPPRESED="
satosa_1 | ],
satosa_1 | "displayName": [
satosa_1 | "Chris Phillips"
satosa_1 | ]
satosa_1 | }
satosa_1 | [2019-07-19 02:21:07] [DEBUG]:
[urn:uuid:d7919f3e-0361-4ec5-aa1b-b5560eb6305c] Routing to frontend:
Saml2IDP
satosa_1 | [2019-07-19 02:21:07] [DEBUG]:
[urn:uuid:d7919f3e-0361-4ec5-aa1b-b5560eb6305c] *Filter: []*
*satosa_1* *|** [2019-07-19 02:21:07] [DEBUG]:
[urn:uuid:d7919f3e-0361-4ec5-aa1b-b5560eb6305c] returning attributes {}*
satosa_1 | [2019-07-19 02:21:07] [DEBUG]:
[urn:uuid:d7919f3e-0361-4ec5-aa1b-b5560eb6305c] signing with algorithm
http://www.w3.org/2001/04/xmldsig-more#rsa-sha256
satosa_1 | [2019-07-19 02:21:07] [DEBUG]:
[urn:uuid:d7919f3e-0361-4ec5-aa1b-b5560eb6305c] using digest algorithm
http://www.w3.org/2001/04/xmlenc#sha256
satosa_1 | [2019-07-19 02:21:07] [DEBUG]:
[urn:uuid:d7919f3e-0361-4ec5-aa1b-b5560eb6305c] Saving state as cookie,
secure: True, max-age: 1200, path: /
_______________________________________________
satosa-users mailing list
satosa-users at lists.sunet.se
https://lists.sunet.se/listinfo/satosa-users
--
____________________
Dott. Giuseppe De Marco
CENTRO ICT DI ATENEO
University of Calabria
87036 Rende (CS) - Italy
Phone: +39 0984 496961
e-mail: giuseppe.demarco at unical.it
7:22 a.m.
Hi Chris,
Re C): I found that the order of attributes for Saml does make the difference:
internal_attributes.yaml
Mail:
Saml: [email, emailAddress, mail]
ist different from
internal_attributes.yaml
Mail:
Saml: [mail, emailAddress, email]
Somewhere it seems to take the first element.
I think that comprehensive logging for attribute mapping should help, because this is not
the only issue.
Re E.) I run into the same problem. The ADFS IDP I am using in the project signs
assertions, but not responses. I configured backend.xml like this:
want_response_signed: false # WKIS signs assertions, not responses ->
clarify
want_assertion_signed: true
This seems to work, although I have not investigated the details.
Did you try to change the ADFS-config to response signing? It will be difficult my current
project, so I cannot try this.
Cheers, Rainer
Am 2019-07-26 um 18:02 schrieb Chris Phillips
<Chris.Phillips at canarie.ca>:
Hi.
I believe I have resolved my issues and have a functioning SATOSA instance in my pre-prod
environment.
I hit 5 main items (so far) and hope that capturing can help others have an easier
story.
I’m interested in helping improve docs and need guidance as to where and how – github
wiki? Fork repo then do a pull request?
Reflections on using SATOSA in pre-prod use marching toward full production use so far:
Starting from zero to this stage was non-small but any other proxy story would have been
more effort IMO.
These items were costly in time to come by and hope that it helps shorten implementations
to capture them.
If I had them, SATOSA is a slam dunk on fastest and ‘thinnest’ deployment.
Kudos to the work put into SATOSA and for future work on the horizon.
Thoughts and questions welcome as always .. my notes and details on how I resolved things
are below.
C
Main challenges and steps taken to have SATOSA operating as expected for attribute
passing and assertion handling
=======================================================
Sp.xml proved impactful on parsing if it had too much in it thus rendering the filter
attributes empty
===========
I had ACS entries for required/requested attributes which seem to have bumped my
internal_attributes filter sufficiently to zero (empirical observation)
My resolution: remove those elements as well as the MD contact info from the sp.xml
metadata appeared to have resolved this first step
Suggestion: more clarity on this element would help.
YAML syntax on how to ingest an aggregate in the ‘backend’ was tough to decipher and
documentation is thin or maybe aged out.
===========
My resulting format working for my docker image: satosa/satosa:latest for the
backend.yaml is:
<snip>
metadata:
remote:
- {url: "https://url.to/fed.xml <https://url.to/fed.xml>", cert:
"/opt/satosa/etc/pki/testfed.crt"}
<snip>
This does not align with documentation that I’ve encountered for SATOSA.
Suggestion: configuration for multi-lateral federation would benefit to be an example. As
would version sensitivity of it and more examples to show what would be sufficient to run
Internal_attributes.yaml mapping transformed email to mail thus downstream was ‘no email,
no access!’
===========
The mapping of email to mail OIDs – YIKES! Who knew that PKCS_9 +1 vs UCL_DIR_PILOT+3
were different? I hated myself on this one
The hurt was in internal_attributes.yaml had
Mail:
Saml: [email, emailAddress, mail]
As such it translated the Shib assertion from ‘mail’ to ‘email’ OID
Action taken to resolve: set saml: [mail] for the mail element
Suggestion: there’s a lot to talk about here on mapping – this is a place for some good
practices and what’s there looks good for just working but the transposition was subtle to
detect. Hard to say how to make it easier without more thought.
Run SATOSA behind apache to trap errors better was tough to find and used a slightly
different way than the WSGI interface
===========
The reference to error handling is a bit oblique as there’s more than one way to do it
and the WSGI apache proxy was not immediately there for me
Here’s the snippet from the apache2 config that allows me to handle the 404’ing of access
for a more graceful error page handling:
#
# proxy SATOSA so we can handle 404's better
# don’t forget to a2en proxy; a2en proxy_http in apache2
# ProxyErrorOverride is **CRITICAL** to trap the 404 passed up by gunicorn.
Proxypass /Saml2 http://127.0.0.1:8000/Saml2 <http://127.0.0.1:8000/Saml2>
ProxyPassReverse /Saml2 http://127.0.0.1:8000/Saml2 <http://127.0.0.1:8000/Saml2>
ProxyErrorOverride On
ErrorDocument 404 /errors/404.html
Suggestion: This is a strong need for error handling. Templating it for the enhancement
listed in the issue tracker not so much as just give me some plain html locations to use
or mount in the container rather than punting to a proxy above resulting in a proxy of a
proxy.
To handle ADFS assertions inbound to SATOSA properly needed the backend.yaml/federation
facing settings to want_response_signed=False and not ‘true’
===========
Testing various IdPs like Shibboleth and ADFS revealed that to use ADFS out of the box
with a SAML trust to SATOSA I needed want_response_signed=False.
This deploys as ‘true’ for SATOSA recommended (and is a good posture to be fair!) but
ADFS won’t play fair with it that I could tell.
This was only uncovered while reading ‘Signature error: Signature missing for respose’ in
google and found this:
https://github.com/IdentityPython/pysaml2/issues/490
<https://github.com/IdentityPython/pysaml2/issues/490>
Suggestion: Again, this is a practitioner configuration. Thankfully the setting is there,
now it needs more revelation in documentation and how to use things and consequences of
the action like this.
From: Chris Phillips <Chris.Phillips at canarie.ca <mailto:Chris.Phillips at
canarie.ca>>
Date: Friday, July 19, 2019 at 8:50 AM
To: "satosa-users at lists.sunet.se <mailto:satosa-users at
lists.sunet.se>" <satosa-users at lists.sunet.se <mailto:satosa-users at
lists.sunet.se>>
Subject: Guidance sought on allowing attributes to pass through with
statosa/statosa:latest
Hi.
I’m trying to work through a SATOSA story of SP with only one IdP configured to be
proxied to use a federation aggregates’ metadata. Sign on is working and always get
Filter: [] and returning attributes {} when I expect attributes to be sent by SATOSA.
I’m using the docker image Latest and have also tried v4.4.0 with same result. I don’t
think I’m too fancy and am using SATOSA ‘out of the box’ and am looking for
guidance/insight/suggestions on what may be wrong, missing, or off by a few columns in
YAML 😊
I have had success in the past at TIIME in Feb2019 with Matt E. but that was non-docker
and a v3.4.8
install:https://lists.sunet.se/pipermail/satosa-users/2019-February/000067.html
<https://lists.sunet.se/pipermail/satosa-users/2019-February/000067.html>
I have seen/explored the microservices/ filter_attributes.yaml.example but that is more
along suppression rather than permit passage. Must I whitelist everything?
Thanks for any insight/guidance on this. I have a gist with front/backends
here:https://gist.github.com/canariecaf/2216d3de5e5872ecaa08cf03548ec559
<https://gist.github.com/canariecaf/2216d3de5e5872ecaa08cf03548ec559>
Happy to jump on Slack and chat there too – is there a slack area for satosa/idpy BTW or
the edugain.slack.com <http://edugain.slack.com/> location have idpy like venues for
chats like this?
C
satosa_1 | [2019-07-19 02:21:07] [DEBUG]:
[urn:uuid:d7919f3e-0361-4ec5-aa1b-b5560eb6305c] Routing path: Saml2/acs/post
satosa_1 | [2019-07-19 02:21:07] [DEBUG]:
[urn:uuid:d7919f3e-0361-4ec5-aa1b-b5560eb6305c] Found registered endpoint: module
name:'Saml2', endpoint: Saml2/acs/post
satosa_1 | [2019-07-19 02:21:07] [DEBUG]: backend attribute '['email',
'emailAdress', 'mail']' mapped to mail
satosa_1 | [2019-07-19 02:21:07] [DEBUG]: skipped backend attribute
'['postaladdress']': no value found
satosa_1 | [2019-07-19 02:21:07] [DEBUG]: skipped backend attribute '['sn',
'surname']': no value found
satosa_1 | [2019-07-19 02:21:07] [DEBUG]: backend attribute
'['displayName']' mapped to displayname
satosa_1 | [2019-07-19 02:21:07] [DEBUG]: skipped backend attribute
'['givenName']': no value found
satosa_1 | [2019-07-19 02:21:07] [DEBUG]: backend attribute
'['eduPersonTargetedID']' mapped to edupersontargetedid
satosa_1 | [2019-07-19 02:21:07] [DEBUG]: skipped backend attribute
'['cn']': no value found
satosa_1 | [2019-07-19 02:21:07] [DEBUG]:
[urn:uuid:d7919f3e-0361-4ec5-aa1b-b5560eb6305c] backend received attributes:
satosa_1 | {
satosa_1 | "eduPersonPrincipalName": [
satosa_1 | "something at canarie.ca <mailto:something at
canarie.ca>"
satosa_1 | ],
satosa_1 | "mail": [
satosa_1 | "Chris.Phillips at canarie.ca <mailto:Chris.Phillips at
canarie.ca>"
satosa_1 | ],
satosa_1 | "eduPersonScopedAffiliation": [
satosa_1 | "staff at canarie.ca <mailto:staff at canarie.ca>"
satosa_1 | ],
satosa_1 | "eduPersonAffiliation": [
satosa_1 | "staff"
satosa_1 | ],
satosa_1 | "eduPersonTargetedID": [
satosa_1 | "SUPPRESED="
satosa_1 | ],
satosa_1 | "displayName": [
satosa_1 | "Chris Phillips"
satosa_1 | ]
satosa_1 | }
satosa_1 | [2019-07-19 02:21:07] [DEBUG]:
[urn:uuid:d7919f3e-0361-4ec5-aa1b-b5560eb6305c] Routing to frontend: Saml2IDP
satosa_1 | [2019-07-19 02:21:07] [DEBUG]:
[urn:uuid:d7919f3e-0361-4ec5-aa1b-b5560eb6305c] Filter: []
satosa_1 | [2019-07-19 02:21:07] [DEBUG]:
[urn:uuid:d7919f3e-0361-4ec5-aa1b-b5560eb6305c] returning attributes {}
satosa_1 | [2019-07-19 02:21:07] [DEBUG]:
[urn:uuid:d7919f3e-0361-4ec5-aa1b-b5560eb6305c] signing with algorithm
http://www.w3.org/2001/04/xmldsig-more#rsa-sha256
<http://www.w3.org/2001/04/xmldsig-more#rsa-sha256>
satosa_1 | [2019-07-19 02:21:07] [DEBUG]:
[urn:uuid:d7919f3e-0361-4ec5-aa1b-b5560eb6305c] using digest algorithm
http://www.w3.org/2001/04/xmlenc#sha256 <http://www.w3.org/2001/04/xmlenc#sha256>
satosa_1 | [2019-07-19 02:21:07] [DEBUG]:
[urn:uuid:d7919f3e-0361-4ec5-aa1b-b5560eb6305c] Saving state as cookie, secure: True,
max-age: 1200, path: /
_______________________________________________
satosa-users mailing list
satosa-users at lists.sunet.se <mailto:satosa-users at lists.sunet.se>
https://lists.sunet.se/listinfo/satosa-users
<https://lists.sunet.se/listinfo/satosa-users>
1754
days inactive
1758
days old
2 comments
3 participants
participants (3)
-
Chris.Phillips＠canarie.ca -
giuseppe.demarco＠unical.it -
rh＠identinetics.com