Hi all,
I am a developer working on an open source project called SimplyE which is
an eBook platform originally developed by the New York Public Library, but
now being used by many public libraries across the US.
The company I work for (Lyrasis) is currently adding support for university
libraries, and with that comes supporting SAML. We are looking for someone
experienced in federated authentication to assist us in this, and I thought
I would reach out here to see if anyone is looking for contract work.
If you are interested, or know anyone who might be, please be in touch with
me via this email.
Thanks so much,
Kristo
Since I've been able to answer my own question about manual client
registration (w/o MongoDB) in another thread (now resolved)
https://lists.sunet.se/pipermail/satosa-users/2020-March/000120.html
I'm starting a new thread about the latter (unrelated) issue:
Starting at the oidc-enabled app I'm sent to satosa with an auth
request, the client is now known/found (client_db details shared at
the above URL), the saml backend is involked, SAML WebSSO happens,
attributes are mapped and I am back "Routing to frontend: oidc".
Then satosa raises an InvalidAuthorizationCode exception:
[pyop.authz_state.create_authorization_code] creating authz code for scope=openid email profile
[pyop.authz_state.create_authorization_code] new authz_code=eff...cd79 to client_id=someClientId for sub=someid at example.org valid_until=1585612419
...
[satosa.proxy_server.unpack_request] read request data: {'grant_type': 'authorization_code', 'code': 'eff...cd79', 'redirect_uri': 'https://some.example.org/auth/callback'}
...
[pyop.client_authentication.verify_client_authentication] client authentication in Authorization header Basic base64-encoded-client_id_colon_client_secret
[satosa.frontends.openid_connect.token_endpoint] invalid request: eff...cd79 unknown
Traceback (most recent call last):
File "/usr/local/venv/SATOSA/lib/python3.7/site-packages/satosa/frontends/openid_connect.py", line 363, in token_endpoint
response = self.provider.handle_token_request(urlencode(context.request), headers)
File "/usr/local/venv/SATOSA/lib/python3.7/site-packages/pyop/provider.py", line 324, in handle_token_request
return self._do_code_exchange(token_request, extra_id_token_claims)
File "/usr/local/venv/SATOSA/lib/python3.7/site-packages/pyop/provider.py", line 352, in _do_code_exchange
authentication_request = self.authz_state.get_authorization_request_for_code(token_request['code'])
File "/usr/local/venv/SATOSA/lib/python3.7/site-packages/pyop/authz_state.py", line 320, in get_authorization_request_for_code
raise InvalidAuthorizationCode('{} unknown'.format(authorization_code))
pyop.exceptions.InvalidAuthorizationCode: eff...cd79 unknown
So the authz code created above (first line) is now unkown (last line).
Why would that happen and what can I do to avoid it?
On the RP side (seemingly using
https://www.npmjs.com/package/openid-client) I currently only see the
same thing as RP is merely relaying the OP error, it seems. And this
being an OP error I probably don't have to dig into the RP side to get
more/better logging:
OPError: invalid_grant (eff...cd79 unknown)
at processResponse (/opt/edumeet/mm/server/node_modules/openid-client/lib/helpers/process_response.js:45:13)
at Client.grant (/opt/edumeet/mm/server/node_modules/openid-client/lib/client.js:1235:26)
at process._tickCallback (internal/process/next_tick.js:68:7)
I'd appreciate suggestions on what I could have done wrong following
the satosa documentation where available, or how to further debug this
issue.
If other/more information (config details, logs, etc.) are needed or
my obscuring of details above is unclear I'm happy to provide those.
-peter
Hej,
I'm looking at an application (eduMEET, a custom frontend for
mediasoup, AFAICT) that comes with OIDC support but needs to be made
available to our SAML federation members, of course.
satosa seems to be a common choice for this (though I wouldn't be
unhappy if I could avoid protocol translation, e.g. by proxying from
httpd+mod_shib).
I'm going with the current (6.1.0) satosa release from the cheeseshop.
Ignoring my failed attempts to deploy this in uwsgi for now, I start
the application and everything seems to be going well (using
Gunicorn plus HTTP proxying and TLS-offloading):
* I've configured the SAML backend including a remote metadata url and
cert and the logs indicate the metadata is being consumed.
* I've "configured" (guessed at a few things) but not yet used the OIDC frontend.
* No microservices as of yet.
[2020-03-26 11:43:13 +0000] [7135] [INFO] Starting gunicorn 20.0.4
[2020-03-26 11:43:13 +0000] [7135] [INFO] Listening at: http://127.0.0.1:8080 (7135)
[2020-03-26 11:43:13 +0000] [7135] [INFO] Using worker: sync
[2020-03-26 11:43:13 +0000] [7138] [INFO] Booting worker with pid: 7138
[2020-03-26 11:43:13,860] [INFO] [satosa.base.__init__] Loading backend modules...
[2020-03-26 11:43:13,936] [DEBUG] [saml2.httpbase.send] GET to https://eduid.at/md/aconet-registered.xml
[2020-03-26 11:43:14,003] [DEBUG] [saml2.httpbase.send] Response status: 200
[2020-03-26 11:43:14,003] [DEBUG] [saml2.httpbase.set_cookie] eduid.at: 'Set-Cookie: ...'
[2020-03-26 11:43:14,606] [DEBUG] [saml2.sigver._run_xmlsec] xmlsec command: /usr/bin/xmlsec1 --verify --enabled-reference-uris empty,same-doc --pubkey-cert-pem aconet-metadata-signing.crt --id-attr:ID urn:oasis:names:tc:SAML:2.0:metadata:EntitiesDescriptor --output /tmp/tmp9gt_vrc6.xml /tmp/tmpmhnh96n3.xml
[2020-03-26 11:43:14,681] [INFO] [satosa.plugin_loader.load_backends] Setup backends: ['saml']
[2020-03-26 11:43:14,681] [INFO] [satosa.base.__init__] Loading frontend modules...
[2020-03-26 11:43:14,804] [INFO] [satosa.plugin_loader.load_frontends] Setup frontends: ['oidc']
[2020-03-26 11:43:14,804] [INFO] [satosa.base.__init__] Loading micro services...
[2020-03-26 11:43:14,804] [INFO] [satosa.plugin_loader.load_request_microservices] Loaded request micro services: []
[2020-03-26 11:43:14,804] [INFO] [satosa.plugin_loader.load_response_microservices] Loaded response micro services:[]
[2020-03-26 11:43:14,805] [DEBUG] [satosa.routing.__init__] Loaded backends with endpoints: [<satosa.backends.saml2.SAMLBackend object at 0x7f45e59ad0b8>]
[2020-03-26 11:43:14,805] [DEBUG] [satosa.routing.__init__] Loaded frontends with endpoints: [<satosa.frontends.openid_connect.OpenIDConnectFrontend object at 0x7f45e54d3b70>]
[2020-03-26 11:43:14,806] [DEBUG] [satosa.routing.__init__] Loaded micro services with endpoints: []
So far so good.
I've also used `satosa-saml-metadata` to generate backend.xml. That
contained a copy of the provided SAML SP certificate, though with a
use="signing" restriction. (I.e., the metadata generated that way
would fail with any default Shibboleth IDP. Unless pysaml2 doesn't
support encrypted assertions or reponses I consider this a bug. At
least neither the satosa nor the pysaml2 docs had anything on this.)
So I've removed that 'use' restriction to cause the IDP to send
encrypted assertions but later also /disabled/ that in the IDP again:
I get the same exception either way, so this may not in fact be
related.
With no idea how to test the SAML side of things (I know nothing about
OIDC and so left the OP setup and RP integration for later) I sent the
SP an unsolilcited response from my IDP. ('allow_unsolicited: True' is
set in the SAML backend config) which ultimately fails with an
"Unknown error". Stdout from Gunicorn below:
[2020-03-26 11:43:41,080] [DEBUG] [satosa.proxy_server.unpack_post] unpack_post:: {'SAMLResponse': ...
[2020-03-26 11:43:41,081] [DEBUG] [satosa.proxy_server.unpack_request] read request data: {'SAMLResponse': ...
[2020-03-26 11:43:41,081] [INFO] [satosa.base._load_state] [urn:uuid:b370f69a-d7e2-49b6-9e32-e31920b89d59] Loaded state {'SESSION_ID': 'urn:uuid:b370f69a-d7e2-49b6-9e32-e31920b89d59'} from cookie
[2020-03-26 11:43:41,081] [DEBUG] [satosa.routing.endpoint_routing] [urn:uuid:b370f69a-d7e2-49b6-9e32-e31920b89d59] Routing path: saml/acs/post
[2020-03-26 11:43:41,082] [DEBUG] [satosa.routing._find_registered_endpoint_for_module] [urn:uuid:b370f69a-d7e2-49b6-9e32-e31920b89d59] Found registered endpoint: module name:'saml', endpoint: saml/acs/post
[2020-03-26 11:43:41,083] [DEBUG] [saml2.response._loads] xmlstr: ...
[2020-03-26 11:43:41,086] [DEBUG] [saml2.sigver._check_signature] ==== Certs from metadata ==== https://idp.example.edu/saml: [<tempfile._TemporaryFileWrapper object at 0x7f45e67d67b8>, <tempfile._TemporaryFileWrapper object at 0x7f45e67d67f0>] ====
[2020-03-26 11:43:41,086] [DEBUG] [saml2.sigver._run_xmlsec] xmlsec command: /usr/bin/xmlsec1 --verify --enabled-reference-uris empty,same-doc --pubkey-cert-pem /tmp/tmpqaj6buom.pem --id-attr:ID urn:oasis:names:tc:SAML:2.0:protocol:Response --node-id _b2ea47f03f30638517a9649f8baf4e1f --output /tmp/tmphc_hm0cw.xml /tmp/tmp8mavdoev.xml
[2020-03-26 11:43:41,098] [DEBUG] [saml2.response._postamble] response: ...
[2020-03-26 11:43:41,103] [DEBUG] [saml2.entity._parse_response] XMLSTR: b'...'
[2020-03-26 11:43:41,103] [INFO] [saml2.response.status_ok] status: <ns0:Status xmlns:ns0="urn:oasis:names:tc:SAML:2.0:protocol"><ns0:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success" /></ns0:Status>
[2020-03-26 11:43:41,104] [DEBUG] [saml2.response.parse_assertion] ***Encrypted assertion/-s***
[2020-03-26 11:43:41,105] [DEBUG] [saml2.response.parse_assertion] --- AVA: {}
[2020-03-26 11:43:41,105] [ERROR] [satosa.base.run] [urn:uuid:b370f69a-d7e2-49b6-9e32-e31920b89d59] Uncaught exception
Traceback (most recent call last):
File "/usr/local/venv/SATOSA/lib/python3.7/site-packages/satosa/base.py", line 289, in run
resp = self._run_bound_endpoint(context, spec)
File "/usr/local/venv/SATOSA/lib/python3.7/site-packages/satosa/base.py", line 229, in _run_bound_endpoint
return spec(context)
File "/usr/local/venv/SATOSA/lib/python3.7/site-packages/satosa/backends/saml2.py", line 341, in authn_response
if context.state[self.name]["relay_state"] != context.request["RelayState"]:
File "/usr/local/venv/SATOSA/lib/python3.7/collections/__init__.py", line 1025, in __getitem__
raise KeyError(key)
KeyError: 'saml'
[2020-03-26 11:43:41,106] [ERROR] [satosa.proxy_server.__call__] Unknown error
Traceback (most recent call last):
File "/usr/local/venv/SATOSA/lib/python3.7/site-packages/satosa/base.py", line 289, in run
resp = self._run_bound_endpoint(context, spec)
File "/usr/local/venv/SATOSA/lib/python3.7/site-packages/satosa/base.py", line 229, in _run_bound_endpoint
return spec(context)
File "/usr/local/venv/SATOSA/lib/python3.7/site-packages/satosa/backends/saml2.py", line 341, in authn_response
if context.state[self.name]["relay_state"] != context.request["RelayState"]:
File "/usr/local/venv/SATOSA/lib/python3.7/collections/__init__.py", line 1025, in __getitem__
raise KeyError(key)
KeyError: 'saml'
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/usr/local/venv/SATOSA/lib/python3.7/site-packages/satosa/proxy_server.py", line 117, in __call__
resp = self.run(context)
File "/usr/local/venv/SATOSA/lib/python3.7/site-packages/satosa/base.py", line 307, in run
raise SATOSAUnknownError("Unknown error") from err
satosa.exception.SATOSAUnknownError: Unknown error
Now, the KeyError comes from the 'name' of my SAML backend plugin config:
module: satosa.backends.saml2.SAMLBackend
name: saml
So when context.state[self.name] doesn't exist (or doesn't have a
"relay_state" key itself) in authn_response() from
satosa/backends/saml2.py I guess something about the relaystate of
COOKIE_STATE_NAME or my deployment could be off?
Here's that part from my proxy_conf.yaml (I haven't checked the code
yet what the defaults are, the documentation doesn't mention any):
BASE: https://test.example.edu
COOKIE_STATE_NAME: satosa_state
# Also tried with delete set to False
CONTEXT_STATE_DELETE: True
STATE_ENCRYPTION_KEY: somestring
cookies_samesite_compat:
- [satosa_state, "SATOSA_STATE_LEGACY"]
Another data point: When trying to start SAML SSO by accessing the
discovery_response endpoint at <base>/<name>/disco I end up with the
exception raised in disco_response() from satosa/backends/saml2.py
("No IDP chosen for state" / "No IDP chosen")
Any pointers?
Should I post (even) more config snippets?
Logs from the other exception too, when accessing the disco endpoint?
Cheers,
-peter
Hi SATOSA users,
Currently, we are working on SSO project which is Zoom SSO service.
We use SATOSA proxy in order to connect with our identity federation (one-to-many type), and we have already implemented single sign-on (SSO) service and it's working, however we still require single logout service (SLO).
We couldn't find any SATOSA configuration regarding to SLO from SATOSA documentation.
Without SLO, although user has already selected and clicked log out from Zoom, the session still there, otherwise user requires to clear the browser cache.
Could you explain to us, how to implement SLO in SATOSA?
Thank you.
----------------
Best regards,
Mr. Ferdy Mulyadi
Research Assistant
Internet Innovation Research Team (INO - CNWRG)
National Electronics and Computer Technology Center (NECTEC)
National Science and Technology Department Agency (NSTDA)
Thailand Science Park (TSP) - 112 Phaholyothin Rd., Khlong Nueng, Khlong Luang
Pathum Thani, THAILAND
________________________________
Disclaimer:
This e-mail and any files transmitted with it may contain confidential and proprietary information of the National Science and Technology Development Agency (NSTDA), Thailand. They are intended solely for the use of the addressed individuals or entities. If you are not the intended recipient, you are required to immediately delete this e-mail and its contents from your system. Any disclosure, distribution, or action based upon the contents of this e-mail is strictly prohibited. Any views or opinions presented in this e-mail are solely those of the sender and do not necessarily represent those of NSTDA. NSTDA does not accept any responsibility for the content of this message or the consequences of any actions taken on the basis of the information provided. NSTDA accepts no liability for any damage caused by any virus or malware which may be inserted in this e-mail during transmission.
Hi,
we are using SATOSA to allow EduGAIN users to access our services. The service is protected by KeyCloak and in KeyCloak we configured SATOSA as a SAML Identity Provider.
Users from the EduGAIN access-check IdP can now access the service, but it looks like we have problems with some IdP's which don't have a signing key in the EduGAIN metadata.
When looking in file '/opt/satosa/lib/python3.5/site-packages/saml2/sigver.py' there is a flag 'only_use_keys_in_metadata' which looks to be set to True, which means that only signing keys from the metadata files are allowed. When I hardcode this flag to be set to False, also users from IdP's without a signing key can authenticate, but I can't seem to find where I can configure this in the SATOSA saml2_backend.yaml file. Is it possible to configure this flag in SATOSA?
Thanks,
Dirk
Indien u VITO Mol bezoekt, hou aub er dan rekening mee dat de hoofdingang voortaan enkel bereikbaar is vanuit de richting Dessel-Retie, niet vanuit richting Mol, zie vito.be/route.<http://www.vito.be/route>
If you plan to visit VITO at Mol, then please note that the main entrance can only be reached coming from Dessel-Retie and no longer coming from Mol, see vito.be/en/contact/locations.<http://www.vito.be/en/contact/locations>
VITO Disclaimer: http://www.vito.be/e-maildisclaimer
Hi all,
Our SP application connects to an identity federation via Satosa. We have
two authentication flows, one which starts the authentication process using
SAML and one which starts the authentication flow using OIDC. The entire
process works well when using OIDC only, however, a requirement is that we
can start the same process via SAML.
After authentication (via SAML) is completed, the SP application tries to
- Request a code
- Request an OIDC access token using the code
- Check the access token using the userinfo endpoint
The issue that we are facing in the flow which starts the authentication by
SAML, is that the user is presented with the WAYF page twice. The first
time during the SAML flow, and the second time when requesting an OIDC
code. I assumed that because the user had just authenticated themselves,
Satosa would be able to return a code without asking the user to
authenticate again.
My questions are:
- Have I made a mistake in assuming this is a logical process to use for
authentication and authorisation? Is using SAML and OIDC in a mixed way a
bad idea?
- Is it possible to receive a OIDC code or access token as a result of a
SAML authentication flow?
- If not, is it possible to receive a code or access token without asking
the user to authenticate once again? I would imagine setting Satosa to
'remember IdP' would forgo the second round of authentication when using
SAML. Are there other options of achieving this?
Thank you in advance.
Kind regards,
Jonathan Blok
--
Kind regards,
*Jonathan Blok*
Technical Project Officer / Software Developer
*T* +31 35 - 677 16 79 | *M* +31 6 - 4 669 14 58
*Availability:* Mon, Tue, Wed, Fri
<http://www.beeldengeluid.nl/>
*Netherlands Institute for Sound and Vision | Nederlands Instituut voor
Beeld en Geluid*
*Media Parkboulevard 1, 1217 WE Hilversum | Postbus 1060, 1200 BB
Hilversum | *
*beeldengeluid.nl* <http://www.beeldengeluid.nl/>
<http://files.beeldengeluid.nl/handtekening/index.html>
I will have some SPs behind the proxy that need to use the refeds MFA profile via InCommon along with other SPs behind the same proxy that only require simple one-step password authentication. I’ve looked through the list archives and don’t see a solution to the problem I’m having.
I can verify by watching the browser saml flow that the SP is correctly requesting refeds mfa in RequestedAuthnContext. However, this request does not appear to be passed on to the selected IdP and the MFA authentication attribute is not set upon return.
There appears to be configuration available (acr_mapping) to specify what AuthnContextClassRef value satosa returns to the SP based on the selected IdP but that is not what we need for this application.
My question: is satosa supposed to pass the SP’s requested AuthnContext to the end user’s IdP and pass back the IdP’s response?
I’ll dig some more but am hoping that someone already knows how/if this should work in satosa.
Thanks much, Jim
Hi Satosa users,
I’m trying to add the Swiss eduPerson attributes [1] to the Satosa attribute maps [2] but running into problems when trying to use them. I’m running Satosa with Docker and have pulled the swiss attributes into .py files in the attributemaps folder, added them to my internal_attribute.yaml schema, restarted my container… however they don’t seem to be recognised.
==========================
The attribute coming from my IdP
==========================
<ns0:Attribute FriendlyName="swissEduPersonHomeOrganization" Name="urn:oid:2.16.756.1.2.5.1.1.4" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"><ns0:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xsi:type="xs:string">cern.ch</ns0:AttributeValue></ns0:Attribute>
====================================================
The config in internal_attribute.yaml (I just want to pass the attribute straight through to my Eps)
====================================================
swissedupersonhomeorganization:
saml: [swissEduPersonHomeOrganization]
==========================
Debug messages
==========================
"Unknown attribute name: <ns0:Attribute xmlns:ns0="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" FriendlyName="swissEduPersonHomeOrganization" Name="urn:oid:2.16.756.1.2.5.1.1.4" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"><ns0:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xsi:type="xs:string">cern.ch</ns0:AttributeValue></ns0:Attribute>”
...
"skipped backend attribute '['swissEduPersonHomeOrganization']': no value found”
The OID appears to be correct (SWISSEDUPERSON_OID = 'urn:oid:2.16.756.1.2.5.1.1.’, SWISSEDUPERSON_OID+’4' =‘swissEduPersonHomeOrganization’). Am I missing something? Some missing config or some cache somewhere?
Thanks in advance for any advice,
Hannah
[1] https://www.switch.ch/aai/docs/AAI_Attr_Specs.pdf
[2] https://github.com/IdentityPython/SATOSA/pull/270
Hi to everybody,
I'm doing fine with pyMultiLDAP as MS [3].
I can test multiple LDAP connections with received, aggregated and
rewritten data directly with pymultildap from command line, before move
configuration to deployed systems.
The same settings[1] used command line would be used in MS configuration,
as is.
I'm using multildap in satosa, in my pysaml2 Idp[2] and also as general
purpose LDAP proxy for SEARCH and BIND methods, with the help of slapd-sock.
At this moment I do not need too much parameters per SP in the MS
configuration but probably in the future I will. I preferred to delegate
data behaviour directly in multildap.settings instead of MS configuration.
I share as it come,
regards
[1]
https://github.com/peppelinux/pyMultiLDAP/blob/master/examples/settings.py.…
<https://github.com/peppelinux/pyMultiLDAP/blob/master/examples/settings.py.…>
[2] https://uniauth.readthedocs.io/en/latest/index.html
[3]
https://github.com/peppelinux/pyMultiLDAP/tree/fe602e39240d6a3240f09c852cb6…
--
____________________
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
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: /
