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
We have a satosa instance running as a social-saml gateway: Frontend=saml; backend=google.
It is behind Apache and accessed by mod_rewrite, essentually:
RewriteRule ^/(.*)$ https://localhost:7445/$1 [P]
This works, but the https seems unnecessary. It would be more efficient to use simple http for the localhost rewrite.
However, that fails with a "Not destined for me!" in request.py's _verify -- simply because http is not https.
Is there a way to use simple http but avoid the error? Commenting out the "raise OtherError" works, but I'd rather not have to edit the sources.
Thanks,
Jim Fox
University of Washington
I've got SATOSA running with mod_wsgi
I'm trying to use OIDC on the frontend and SAML2 on the backend, and I
think that I have the SAML stuff misconfigured.
Acc'd to /satosa/.well-known/openid-configuration, my OIDC authorization
endpoint is
https://satosa.example.org/satosa/Saml2/OIDC/authorization
but any attempt to interact with that URL returns a 404.
The OIDC frontend stuff seems to be working - visiting the URLs with
various (in)appropriate requests generates responses.
Do I need to do something in addition to setting BASE in proxy_conf.yaml to
get SATOSA's routing to work through URLs that aren't immediately off the
server root?
thanks
Liam
SATOSA won't start If I comment out the db_uri /or/ leave it blank.
If I don't assign a db_uri, it *does* get set to None, but I get
"MissingRequiredAttribute("token_endpoint")".
Traceback (most recent call last):
File
"/opt/local/satosa/lib/python3.5/site-packages/satosa/proxy_server.py",
line 148, in make_app
return ToBytesMiddleware(WsgiApplication(satosa_config))
File
"/opt/local/satosa/lib/python3.5/site-packages/satosa/proxy_server.py",
line 90, in init
super().init(config)
File "/opt/local/satosa/lib/python3.5/site-packages/satosa/base.py", line
68, in init
self.request_micro_services + self.response_micro_services)
File "/opt/local/satosa/lib/python3.5/site-packages/satosa/routing.py",
line 59, in init
for instance in frontends}
File "/opt/local/satosa/lib/python3.5/site-packages/satosa/routing.py",
line 59, in
for instance in frontends}
File
"/opt/local/satosa/lib/python3.5/site-packages/satosa/frontends/openid_connect.py",
line 163, in register_endpoints
self._create_provider(endpoint_baseurl)
File
"/opt/local/satosa/lib/python3.5/site-packages/satosa/frontends/openid_connect.py",
line 83, in _create_provider
self.provider = Provider(self.signing_key, capabilities, authz_state, cdb,
Userinfo(self.user_db))
File "/opt/local/satosa/lib/python3.5/site-packages/pyop/provider.py", line
71, in init
self.configuration_information.verify()
File "/opt/local/satosa/lib/python3.5/site-packages/oic/oic/message.py",
line 877, in verify
raise MissingRequiredAttribute("token_endpoint")
oic.oauth2.message.MissingRequiredAttribute: Missing required attribute
'token_endpoint'