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
>
We have to send asssertions with emailAddress nameids. This is for a saml
frontend and oidc backend. For now I'm using local patched code, but I'd
prefer to not do that.
I see a pull request (#137) that suggests it would provide the capability.
It seems to be inactive. Is there any chance of it getting merged?
Thanks,
Jim Fox
Univ. of Washington
Hi,
If you are not using the LDAP attribute store microservice for SATOSA
then this note does not concern you. Otherwise please read on...
An updated SATOSA LDAP attribute store microservice with LDAP
connection pooling will be merged today into the satosa_microservice GitHub
repository at
https://github.com/IdentityPython/satosa_microservices
Note that this is NOT the SATOSA repository. Microservices are being
migrated to a new repository and will only be removed from the main
SATOSA repository as part of the next major SATOSA release. New
development for the microservices, however, is primarily taking place in
the new microservices repository.
The updated LDAP attribute store microservice has new functionality AND
a breaking configuration change.
The new functionality is LDAP connection pooling, which provides
substantially better throughput performance as you would expect.
The breaking configuration change is a result of harmonizing the way
microservices are configured, particularly with respect to default
configurations versus per-SP overrides. See the example configuration at
https://github.com/IdentityPython/satosa_microservices/blob/master/example/…
for details. In short, the default configuration must now be labeled as
such using "" or "default". Per-SP overrides remain the same.
Please let me know if you have any questions or concerns.
Thanks,
Scott K
Hi,
I would like SATOSA to receive a SAML assertion from an IdP and check
for a configured set of asserted attributes such as the REFEDs R&S
bundle. If the configured set of asserted attributes is not present
then SATOSA should redirect the browser to an external "error page" to
manage the situation.
I do not see an existing SATOSA microservice that can implement that
requirement. Am I correct?
The primary_identifier microservice can do that for a single identifier
but not for a set of attributes.
If no such microservice (or combination of microservices) can do that
today, I will probably proceed with writing such a microservice. If you
want to input to the requirements and/or design please let me know.
Thanks,
Scott K
Hello,
Our SP is a Dynamics 365 Portal, S2S as SAML2SAML proxy, backend gets metadata from SWAMID, frontend act as IdP for our portal.
Getting the following error, it always stop at “returning attributes”.
Could it possibly be a problem with self-signed SSL certificate that Microsoft CRM Portal does not accept or is any parties not accepting SHA256?
Or is there anything else that I forgot to configure?
Thanks for any help from you guys. The end of the debug log is below.
Mats
[2017-10-19 13:07:26] [DEBUG]: [urn:uuid:2daabe4d-92c3-434e-b743-fddd2002878b] Routing to frontend: Saml2IDP
[2017-10-19 13:07:26] [DEBUG]: [urn:uuid:2daabe4d-92c3-434e-b743-fddd2002878b] Filter: ['givenname', 'mail', 'edupersontargetedid', 'displayname', 'surname', 'name']
[2017-10-19 13:07:26] [DEBUG]: frontend attribute givenName mapped from givenname
[2017-10-19 13:07:26] [DEBUG]: frontend attribute eduPersonTargetedID mapped from edupersontargetedid
[2017-10-19 13:07:26] [DEBUG]: frontend attribute email mapped from mail
[2017-10-19 13:07:26] [DEBUG]: frontend attribute sn mapped from surname
[2017-10-19 13:07:26] [DEBUG]: frontend attribute cn mapped from name
[2017-10-19 13:07:26] [DEBUG]: frontend attribute displayName mapped from displayname
[2017-10-19 13:07:26] [DEBUG]: [urn:uuid:2daabe4d-92c3-434e-b743-fddd2002878b] returning attributes {"email": [“XXX.XXX at XXX.XXX.XXX <mailto:XXX.XXX at XXX.XXX.XXX>"], "cn": [“XXX XXX"], "eduPersonTargetedID": [“XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"], "sn": [“XXX"], "givenName": [“XXX"], "displayName": ["Mats Liu"]}
[2017-10-19 13:07:26] [DEBUG]: [urn:uuid:2daabe4d-92c3-434e-b743-fddd2002878b] signing with algorithm http://www.w3.org/2001/04/xmldsig-more#rsa-sha256
[2017-10-19 13:07:26] [DEBUG]: [urn:uuid:2daabe4d-92c3-434e-b743-fddd2002878b] using digest algorithm http://www.w3.org/2001/04/xmlenc#sha256
[2017-10-19 13:07:26] [DEBUG]: [urn:uuid:2daabe4d-92c3-434e-b743-fddd2002878b] Saving state as cookie, secure: True, max-age: 1200, path: /
[2017-10-19 13:07:26] [DEBUG]: read request data: {}
[2017-10-19 13:07:26] [DEBUG]: Did not find cookie named 'SATOSA_STATE' in cookie string ''
[2017-10-19 13:07:26] [DEBUG]: [urn:uuid:33b0dd08-5a33-4873-b6d9-1efd3421575b] Routing path: favicon.ico
[2017-10-19 13:07:26] [DEBUG]: [urn:uuid:33b0dd08-5a33-4873-b6d9-1efd3421575b] Unknown backend favicon.ico
Hi,
I am planning to aggregate and manage a couple of different sources of SAML
metadata using pyFF to then expose it for consumption by SATOSA.
My first thought was to have pyFF dump an XML of the aggregate to the file
system and point SATOSA (really pysaml2) at it. But I don't see that the
"local" method for SATOSA/pysaml2 to consume metadata ever refreshes what
it finds on the file system--it appears to read it once but never again. I
need SATOSA to be consuming "fresh" metadata at least every 24 hours.
A second option might be to leverage the pysaml2 "loader" functionality and
pass in my own callable for reading in the metadata from the file system
periodically. But again I don't see that once pysaml2 has the internal
representation of the metadata that it would ever invoke my callable again.
Is that true?
So what I will probably do is operate pyFF as a MDQ server and leverage the
pysaml2 "mdq" functionality.
How are other SATOSA deployers making sure that SATOSA has "fresh" SAML
metadata?
Thanks,
Scott K
