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
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'
