Hello,
(Apologies, cross posting from Slack)
I’m having a strange error with my Satosa frontend that seems to be
stripping out attributes incorrectly from the SAML response before it is
sent, based on required attributes from SP metadata.
It receives the correct values from an upstream IdP:
returning attributes {"eduPersonUniqueId": ["... at cern.ch"], "displayName":
["Hannah Short"], "givenName": ["Hannah"], "mail": ["hannah.short at cern.ch"],
"cn": ["Hannah Short"], "sn": ["Short"], "eduPersonScopedAffiliation": ["
member at cern.ch"], "eduPersonAffiliation": ["member"],
"eduPersonPrincipalName": ["hshort at cern.ch"], "eduPersonAssurance": ["
https://refeds.org/assurance/ID/unique", "
https://refeds.org/assurance/ATP/ePA-1m", "
https://refeds.org/assurance/IAP/low"], "schacHomeOrganization": ["cern.ch"],
"schacHomeOrganizationType": ["urn:schac:homeOrganizationType:ch:others"],
"swissEduPersonHomeOrganization": ["cern.ch"],
"swissEduPersonHomeOrganizationType": ["others"], "swissEduPersonUniqueID":
["... at cern.ch"], "eduPersonTargetedID": ["..."]}
However, it then checks the “required” attributes from the target SP and
decides to strip out the swiss* ones (despite them being required in the
SP’s metadata and I can also see that they are required in the debug
statement).
My swiss* attributes are defined in an attribute map, and I’m running
satosa 6.0.0.
I’m really stuck here, I just rolled out this IdP and will have to roll
back if I can’t fix this quickly :( Can I ignore “required” attributes as a
workaround? When none are required the token gets sent as expected
Thanks in advance for any help,
Hannah
Hi
I´m trying to setup SAMLVirtualCoFrontend with three entityIDs, but got a problem that I hope someone knows about.
It seems as all three entityIDs are get up by SATOSA as I can see this in the log:
Created URL regex (^Saml2)/(Org1|Org2|Org3)/sso/post
Adding mapping ('(^Saml2)/(Org1|Org2|Org3)/sso/post'
Created URL regex (^Saml2)/(Org1|Org2|Org3)/sso/redirect
Adding mapping ('(^Saml2)/(Org1|Org2|Org3)/sso/redirect'
But the metadata frontend.xml only contains entityID for the last entry, in this case "Org3".
The log shows that metadata is written three times to the same file, see log entry below.
Writing metadata to '/cfg/metadata/frontend.xml'
Writing metadata to '/cfg/metadata/frontend.xml'
Writing metadata to '/cfg/metadata/frontend.xml'
Writing metadata to '/cfg/metadata/backend.xml'
Is there anything I can do to get correct frontend metadata for all three COs ?
A configuration item to get separate filenames or something?
I´m using latest Docker image satosa/satosa as of yesterday
/Ulrik Å
Hello SatoSa list!
This is my first post as I am just getting started with SatoSa. Thanks to all for making it possible. I love it so far, the code and semantics are very clean!
Question: It seems that I can configure SAMLFrontend and SAMLVirtualCoFrontend to both operate correctly in my topology ( 1 or many SP => 1 IdP. OR 1 SP=> many IdP ) as such I am uncertain of which module would be best to use.
Can someone in the community tell me why I would want to use one module over the other? I think I must be missing some functional capabilities afforded by one but not the other.
TIA
-Jonathan
+++
Hi,
I'm having few issues and hopefully you might provide some light
saml to saml scenario.
I wanted to add custom attribute:
I added that attribute to saml_uri.py
'fro': { 'urn:mace:heanet.ie:custom:tenantid': 'customtenantid', ... },
'to': { 'customtenantid': 'urn:mace:heanet.ie:custom:tenantid', ... }
then internal_attributes.yaml :
added:
customtenantid:
saml: [customtenantid, urn:mace:heanet.ie:custom:tenantid]
in saml2_frontend.yaml policy is set to allow release everything:
policy:
default:
attribute_restrictions: null
however: logs say:
///////////////
xx | [2020-07-20 20:59:47,604] [DEBUG] [satosa.frontends.saml2._get_approved_attributes] [urn:uuid:244a93be-a61e-4e5f-8508-c293a24f832d] Filter: ['name', 'schacHomeOrganization', 'edupersontargetedid', 'givenname', 'eppn', 'organizationName', 'mail', 'displayname', 'surname']
//////////////
where does that filter come from if I have set not restriction .
Is it only way to add a custom atribute ?
thanks in advance,
Janusz
Hi,
I hope you might give some light.
I'm trying to setup saml2saml.
Everything works fine when samlBackend gets metadata with only one IdP.
When there is more then I'm getting error.
backends/saml2_backend.yaml is based saml2_backend.yaml.example
I would be very much appreciated for any help.
############################
jagger_satosa.1.niwh0x0v4r34 at totoro | [2020-06-18 14:44:26,978] [DEBUG] [satosa.routing.backend_routing] [urn:uuid:4391da61-03e6-44c3-b706-2f31694b9b33] Routing to backend: Saml2
jagger_satosa.1.niwh0x0v4r34 at totoro | [2020-06-18 14:44:26,978] [INFO] [satosa.backends.saml2.get_idp_entity_id] [urn:uuid:4391da61-03e6-44c3-b706-2f31694b9b33] {'message': 'Selected IdP', 'only_one': False, 'target_entity_id': None, 'force_authn': None, 'memorized_idp': False, 'entity_id': None}
agger_satosa.1.niwh0x0v4r34 at totoro | [2020-06-18 14:44:26,979] [ERROR] [satosa.base.run] [urn:uuid:4391da61-03e6-44c3-b706-2f31694b9b33] Uncaught exception
jagger_satosa.1.niwh0x0v4r34 at totoro | Traceback (most recent call last):
jagger_satosa.1.niwh0x0v4r34 at totoro | File "/src/satosa/src/satosa/base.py", line 240, in run
jagger_satosa.1.niwh0x0v4r34 at totoro | resp = self._run_bound_endpoint(context, spec)
jagger_satosa.1.niwh0x0v4r34 at totoro | File "/src/satosa/src/satosa/base.py", line 180, in _run_bound_endpoint
jagger_satosa.1.niwh0x0v4r34 at totoro | return spec(context)
jagger_satosa.1.niwh0x0v4r34 at totoro | File "/src/satosa/src/satosa/frontends/saml2.py", line 100, in handle_authn_request
jagger_satosa.1.niwh0x0v4r34 at totoro | return self._handle_authn_request(context, binding_in, self.idp)
jagger_satosa.1.niwh0x0v4r34 at totoro | File "/src/satosa/src/satosa/frontends/saml2.py", line 256, in _handle_authn_request
jagger_satosa.1.niwh0x0v4r34 at totoro | return self.auth_req_callback_func(context, internal_req)
jagger_satosa.1.niwh0x0v4r34 at totoro | File "/src/satosa/src/satosa/base.py", line 103, in _auth_req_callback_func
jagger_satosa.1.niwh0x0v4r34 at totoro | return self._auth_req_finish(context, internal_request)
jagger_satosa.1.niwh0x0v4r34 at totoro | File "/src/satosa/src/satosa/base.py", line 108, in _auth_req_finish
jagger_satosa.1.niwh0x0v4r34 at totoro | return backend.start_auth(context, internal_request)
jagger_satosa.1.niwh0x0v4r34 at totoro | File "/src/satosa/src/satosa/backends/saml2.py", line 179, in start_auth
jagger_satosa.1.niwh0x0v4r34 at totoro | return self.disco_query(context)
jagger_satosa.1.niwh0x0v4r34 at totoro | File "/src/satosa/src/satosa/backends/saml2.py", line 211, in disco_query
jagger_satosa.1.niwh0x0v4r34 at totoro | disco_url, self.sp.config.entityid, **args
jagger_satosa.1.niwh0x0v4r34 at totoro | File "/opt/satosa/lib/python3.7/site-packages/saml2/client_base.py", line 936, in create_discovery_service_request
jagger_satosa.1.niwh0x0v4r34 at totoro | if '?' in url:
jagger_satosa.1.niwh0x0v4r34 at totoro | TypeError: argument of type 'NoneType' is not iterable
jagger_satosa.1.niwh0x0v4r34 at totoro | [2020-06-18 14:44:26,980] [ERROR] [satosa.proxy_server.__call__] Unknown error
jagger_satosa.1.niwh0x0v4r34 at totoro | Traceback (most recent call last):
jagger_satosa.1.niwh0x0v4r34 at totoro | File "/src/satosa/src/satosa/base.py", line 240, in run
jagger_satosa.1.niwh0x0v4r34 at totoro | resp = self._run_bound_endpoint(context, spec)
jagger_satosa.1.niwh0x0v4r34 at totoro | File "/src/satosa/src/satosa/base.py", line 180, in _run_bound_endpoint
jagger_satosa.1.niwh0x0v4r34 at totoro | return spec(context)
jagger_satosa.1.niwh0x0v4r34 at totoro | File "/src/satosa/src/satosa/frontends/saml2.py", line 100, in handle_authn_request
jagger_satosa.1.niwh0x0v4r34 at totoro | return self._handle_authn_request(context, binding_in, self.idp)
jagger_satosa.1.niwh0x0v4r34 at totoro | File "/src/satosa/src/satosa/frontends/saml2.py", line 256, in _handle_authn_request
jagger_satosa.1.niwh0x0v4r34 at totoro | return self.auth_req_callback_func(context, internal_req)
jagger_satosa.1.niwh0x0v4r34 at totoro | File "/src/satosa/src/satosa/base.py", line 103, in _auth_req_callback_func
jagger_satosa.1.niwh0x0v4r34 at totoro | return self._auth_req_finish(context, internal_request)
jagger_satosa.1.niwh0x0v4r34 at totoro | File "/src/satosa/src/satosa/base.py", line 108, in _auth_req_finish
jagger_satosa.1.niwh0x0v4r34 at totoro | return backend.start_auth(context, internal_request)
jagger_satosa.1.niwh0x0v4r34 at totoro | File "/src/satosa/src/satosa/backends/saml2.py", line 179, in start_auth
jagger_satosa.1.niwh0x0v4r34 at totoro | return self.disco_query(context)
jagger_satosa.1.niwh0x0v4r34 at totoro | File "/src/satosa/src/satosa/backends/saml2.py", line 211, in disco_query
jagger_satosa.1.niwh0x0v4r34 at totoro | disco_url, self.sp.config.entityid, **args
jagger_satosa.1.niwh0x0v4r34 at totoro | File "/opt/satosa/lib/python3.7/site-packages/saml2/client_base.py", line 936, in create_discovery_service_request
jagger_satosa.1.niwh0x0v4r34 at totoro | if '?' in url:
jagger_satosa.1.niwh0x0v4r34 at totoro | TypeError: argument of type 'NoneType' is not iterable
jagger_satosa.1.niwh0x0v4r34 at totoro |
jagger_satosa.1.niwh0x0v4r34 at totoro | The above exception was the direct cause of the following exception:
jagger_satosa.1.niwh0x0v4r34 at totoro |
jagger_satosa.1.niwh0x0v4r34 at totoro | Traceback (most recent call last):
jagger_satosa.1.niwh0x0v4r34 at totoro | File "/src/satosa/src/satosa/proxy_server.py", line 118, in __call__
jagger_satosa.1.niwh0x0v4r34 at totoro | resp = self.run(context)
jagger_satosa.1.niwh0x0v4r34 at totoro | File "/src/satosa/src/satosa/base.py", line 258, in run
jagger_satosa.1.niwh0x0v4r34 at totoro | raise SATOSAUnknownError("Unknown error") from err
jagger_satosa.1.niwh0x0v4r34 at totoro | satosa.exception.SATOSAUnknownError: Unknown error
############################
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
Not knowing whether my satosa instance is fully working yet (see my
other thread) I'm now continuing to try to get the application
(eduMEET) to work with satosa's oidc frontend, as per the app's
published config example:
https://github.com/havfo/multiparty-meeting/blob/master/server/config/confi…
So I've made up a client_id and client_secret on the RP side and
provided the client with an issuerURL (base URL of satosa), let it
request all the scopes in the world and set its own redirect_uri.
With those all set I do see requests to satosa's .well-known endpoints
from the application in satosa logs, e.g.
Found registered endpoint: module name:'oidc', endpoint: .well-known/openid-configuration
(And of course accessing the endpoint myself I can see that it works
and produces JSON with its config.)
Now on the OP side (satosa oidc frontend) I haven't done any setup
for the client yet, so I guess the error in the log is to be expected:
Error in authn req: Unknown client_id
Now what would be the next steps to register that client?
The request from the client (according to satosa's logs) has these
query parameters (where cid and csec are the correct client_id and
client_secret, respectively):
client_id=cid&scope=openid+email+profile&response_type=code&redirect_uri=https%3A%2F%2Fexample.org%2Fauth%2Fcallback&state=e30%3D&client_secret=csec
My plugins/frontends/openid_connect_frontend.yaml looks like the
published example, essentially:
module: satosa.frontends.openid_connect.OpenIDConnectFrontend
name: oidc
config:
signing_key_path: /etc/satosa/oidc-provider.key
#db_uri: mongodb://db.example.com # optional: only support MongoDB, will default to in-memory storage if not specified
client_db_path: /etc/satosa/oidc-clients.json
provider:
client_registration_supported: True
response_types_supported: ['code', 'token', 'id_token']
subject_types_supported: ['public', 'pairwise']
scopes_supported: ['openid', 'email', 'profile']
Only that I tried to enable pretty much everything (all repose and
subject types, all scopes, client registration) since I had no idea
what the RP side wants, yet. (Seems I can remove all response types
except 'code', as per the log shown above.)
I don't have MongoDB set up yet since the comment above suggests an
in-memory store would be used, which is fine for my current testing.
And looking at _create_provider() at frontends/openid_connect.py the
code would use the file referenced by client_db_path if db_uri isn't
set even before falling back to storing it in a variable.
The file referenced in client_db_path exists, is writable by the user
satosa runs as, and currently contains only '{}' (without the quotes).
So IMO that should be sufficient.
Any hints on how to register the application?
The documenation is a bit sparse here
https://github.com/IdentityPython/SATOSA/blob/master/doc/README.md#frontend…
only mentioning that *without* dynamic client registration (which I
have enabled for now, but maybe the RP doesn't support it) I'd have to
manually create the data structures in MongoDB (or the file in
client_db_path) for my client, as per the oidc spec for Client
Registration Responses.
Could someone share a json sample to put into the file referenced by
client_db_path (if that's how it's supposed to work)?
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.
