Hello satosa users,
O'Reilly Media is working to build out a proper multilateral federation SP
for our platform. We have deployed Shibboleth SP3 for development but are
finding that integrating our existing systems with Shib to be inefficient
and rather kludgy. SATOSA looks like a great fit for our python-based
AuthN/Z OIDC backend but I have only identified a handful of deployments
(E.G. GÉANT and possibly CERN).
We would use it as a SAML backend and OIDC frontend with InCommon's MDQ
feed and, initially, their discovery service as well.
For those who have deployed SATOSA in production, what has your experience
been in terms of reliability and maintainability, either generally or as
compared to Shib SP3? Also, can you share roughly how much ongoing IT and
development time has been needed to maintain a high level of uptime?
I welcome additional feedback and suggestions as well.
Thank you!
-jesse
--
Jesse Banning
Manager of Platform Integration
O'Reilly Media, Inc. <https://oreilly.com> (Boston Office
<https://www.google.com/maps/place/O'Reilly>)
(617)499-7575 | jbanning at oreilly.com
Calendar: https://beta.doodle.com/jbanning
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: /
Is there an option to limit a microservice to either frontend or backend?
If not, I would propose to extend MicroService with 2 bool args, like:
def __init__(self, name, base_url, backend=True, frontend=True, **kwargs):
Thanks, Rainer
Dear Satosa Users,
I'm trying to create a ResponseMicroService which generates a subject identifier of pairwise-id [1] from the eduPersonTargetedID provided by the Home Organization's IdP.
To avoid collisions, I want the input to the generator for the pairwise-id to contain entityID + '!' + eduPersonTargetedID, but the Response Context doesn't appear to contain the entityID of the originating IdP. Evidently I don't understand the model which SATOSA uses to pass information from backend to frontend...
- Is there a way to access the proxied IdP's entityID from a ResponseMicroService?
- Would it be better to generate the attribute in a RequestMicroService?
- Do microservices act in the order that they're defined in proxy_conf.yaml? For example, can I define a microservice to generate the new attribute from an existing attribute, and then filter out the existing attribute.
Any information appreciated.
Thanks,
Alex
[1] SAML subject identifier attributes, https://docs.oasis-open.org/security/saml-subject-id-attr/v1.0/cs01/saml-su…
—
Alex Stuart
Principal technical support specialist (UK federation)
alex.stuart at jisc.ac.uk
Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc’s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800.
Jisc Services Limited is a wholly owned Jisc subsidiary and a company limited by guarantee which is registered in England under company number 2881024, VAT number GB 197 0632 86. The registered office is: One Castle Park, Tower Hill, Bristol BS2 0JA. T 0203 697 5800.
Using a SAMl2SAML configuration I get 'Unsupported sign algorithm http://www.w3.org/2001/04/xmldsig-more#rsa-sha256' <http://www.w3.org/2001/04/xmldsig-more#rsa-sha256'>. pysaml2 does support his since a couple of years.
Has anybody encountered this?
- Rainer
[2019-04-09 21:01:44] [DEBUG]: [urn:uuid:0afc6b35-2ff2-436e-a7db-bb8d2fc877a0] Routing to frontend: Saml2IDP
[2019-04-09 21:01:44] [DEBUG]: [urn:uuid:0afc6b35-2ff2-436e-a7db-bb8d2fc877a0] Filter: ['name', 'telephoneNumber', 'surname', 'givenname', 'mail', 'uid', 'displayname', 'title']
[2019-04-09 21:01:44] [DEBUG]: frontend attribute displayName mapped from displayname
[2019-04-09 21:01:44] [DEBUG]: frontend attribute givenName mapped from givenname
[2019-04-09 21:01:44] [DEBUG]: frontend attribute email mapped from mail
[2019-04-09 21:01:44] [DEBUG]: frontend attribute cn mapped from name
[2019-04-09 21:01:44] [DEBUG]: frontend attribute sn mapped from surname
[2019-04-09 21:01:44] [DEBUG]: frontend attribute uid mapped from uid
[2019-04-09 21:01:44] [DEBUG]: [urn:uuid:0afc6b35-2ff2-436e-a7db-bb8d2fc877a0] returning attributes {"displayName": ["User Test"], "givenName": ["Test"], "email": ["test at bmspot.gv.at"], "cn": ["Test User"], "sn": ["User"], "uid": ["test at bmspot.gv.at"]}
[2019-04-09 21:01:44] [ERROR]: [urn:uuid:0afc6b35-2ff2-436e-a7db-bb8d2fc877a0] Unsupported sign algorithm http://www.w3.org/2001/04/xmldsig-more#rsa-sha256
[2019-04-09 21:01:44] [ERROR]: [urn:uuid:0afc6b35-2ff2-436e-a7db-bb8d2fc877a0] Uncaught exception
Traceback (most recent call last):
File "/opt/venv/lib/python3.6/site-packages/satosa/frontends/saml2.py", line 366, in _handle_authn_response
args['sign_alg'] = getattr(xmldsig, sign_alg)
AttributeError: module 'saml2.xmldsig' has no attribute 'http://www.w3.org/2001/04/xmldsig-more#rsa-sha256'
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/opt/venv/lib/python3.6/site-packages/satosa/base.py", line 286, in run
resp = self._run_bound_endpoint(context, spec)
File "/opt/venv/lib/python3.6/site-packages/satosa/base.py", line 228, in _run_bound_endpoint
return spec(context)
File "/opt/venv/lib/python3.6/site-packages/satosa/backends/saml2.py", line 238, in authn_response
return self.auth_callback_func(context, self._translate_response(authn_response, context.state))
File "/opt/venv/lib/python3.6/site-packages/satosa/base.py", line 197, in _auth_resp_callback_func
context, internal_response)
File "/opt/venv/lib/python3.6/site-packages/satosa/micro_services/attribute_modifications.py", line 17, in process
return super().process(context, data)
File "/opt/venv/lib/python3.6/site-packages/satosa/micro_services/base.py", line 33, in process
return self.next(context, data)
File "/opt/venv/lib/python3.6/site-packages/satosa/base.py", line 168, in _auth_resp_finish
return frontend.handle_authn_response(context, internal_response)
File "/opt/venv/lib/python3.6/site-packages/satosa/frontends/saml2.py", line 84, in handle_authn_response
return self._handle_authn_response(context, internal_response, self.idp)
File "/opt/venv/lib/python3.6/site-packages/satosa/frontends/saml2.py", line 370, in _handle_authn_response
raise Exception(errmsg) from e
Exception: Unsupported sign algorithm http://www.w3.org/2001/04/xmldsig-more#rsa-sha256
[2019-04-09 21:01:44] [ERROR]: Unknown error
Traceback (most recent call last):
File "/opt/venv/lib/python3.6/site-packages/satosa/frontends/saml2.py", line 366, in _handle_authn_response
args['sign_alg'] = getattr(xmldsig, sign_alg)
AttributeError: module 'saml2.xmldsig' has no attribute 'http://www.w3.org/2001/04/xmldsig-more#rsa-sha256'
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/opt/venv/lib/python3.6/site-packages/satosa/base.py", line 286, in run
resp = self._run_bound_endpoint(context, spec)
File "/opt/venv/lib/python3.6/site-packages/satosa/base.py", line 228, in _run_bound_endpoint
return spec(context)
File "/opt/venv/lib/python3.6/site-packages/satosa/backends/saml2.py", line 238, in authn_response
return self.auth_callback_func(context, self._translate_response(authn_response, context.state))
File "/opt/venv/lib/python3.6/site-packages/satosa/base.py", line 197, in _auth_resp_callback_func
context, internal_response)
File "/opt/venv/lib/python3.6/site-packages/satosa/micro_services/attribute_modifications.py", line 17, in process
return super().process(context, data)
File "/opt/venv/lib/python3.6/site-packages/satosa/micro_services/base.py", line 33, in process
return self.next(context, data)
File "/opt/venv/lib/python3.6/site-packages/satosa/base.py", line 168, in _auth_resp_finish
return frontend.handle_authn_response(context, internal_response)
File "/opt/venv/lib/python3.6/site-packages/satosa/frontends/saml2.py", line 84, in handle_authn_response
return self._handle_authn_response(context, internal_response, self.idp)
File "/opt/venv/lib/python3.6/site-packages/satosa/frontends/saml2.py", line 370, in _handle_authn_response
raise Exception(errmsg) from e
Exception: Unsupported sign algorithm http://www.w3.org/2001/04/xmldsig-more#rsa-sha256
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/opt/venv/lib/python3.6/site-packages/satosa/proxy_server.py", line 113, in __call__
resp = self.run(context)
File "/opt/venv/lib/python3.6/site-packages/satosa/base.py", line 302, in run
raise SATOSAUnknownError("Unknown error") from err
satosa.exception.SATOSAUnknownError: Unknown error
Hello,
I have difficulties configuring Satosa in front of my Rocket.Chat
serveur to provide Shibboleth authentication.
I have open an issue on the Github with my configuration files.
I am properly redirected to the WAYF but after the authentication I
have an error.
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xfd in position 0:
invalid start byte
I can not figure out where I am wrong. Could you help me ?
Regards,
Thomas
--
Thomas BellemboisAdministrateur système - IUT/DSI (UCA)Université Clermont Auvergne5 avenue Blaise Pascal - CS 3008663178 Aubière Cedex04.73.17.71.23
I want to again say "thanks" to Ioannis, Rainer, Scott, and everyone
else for their help and instruction during the various IdentityPython
and SATOSA meetings at TIIME this week. Chris Phillips and I were able
to get a SATOSA 3.4.8 deployment working in Chris's idp-installer test
bed. To that end I want to share my notes from the process, at the end
of which an interested party could perform a basic, end-to-end test of
the current SATOSA release using SAMLtest (https://samltest.id/)
1. I installed Ubuntu Server 18.04.1; run the following commands as root
to install the prerequisites:
```sh
apt update
apt dist-upgrade -y
apt install -y git python3-dev build-essential python3-pip libffi-dev
libssl-dev xmlsec1 libyaml-dev libxml2-utils
pip3 install --upgrade virtualenv
virtualenv -p python3 /opt/satosa
/opt/satosa/bin/pip install --upgrade pip setuptools
/opt/satosa/bin/pip install SATOSA
```
This is essentially the Docker image build process, only it uses the
current SATOSA release (etc.) on PyPI.
2. Copy
https://github.com/IdentityPython/SATOSA/tree/v3.4.8/docker/attributemap
s to /opt/satosa/attributemaps.
I'm not sure this is strictly necessary as the built-in pysaml2
attribute maps should be used by default, but it's what the Docker image
build process does.
3. Copy https://github.com/IdentityPython/SATOSA/tree/v3.4.8/example to
/opt/satosa/etc.
4. SATOSA doesn't have a default configuration, so you must provide it
yourself.
```sh
cp /opt/satosa/etc/proxy_conf.yaml.example \
/opt/satosa/etc/proxy_conf.yaml
cp /opt/satosa/etc/internal_attributes.yaml.example \
/opt/satosa/etc/internal_attributes.yaml
cp /opt/satosa/etc/plugins/frontends/saml2_frontend.yaml.example \
/opt/satosa/etc/plugins/frontends/saml2_frontend.yaml
cp /opt/satosa/etc/plugins/backends/saml2_backend.yaml.example \
/opt/satosa/etc/plugins/backends/saml2_backend.yaml
cp /opt/satosa/etc/plugins/microservices/static_attributes.yaml.example
\
/opt/satosa/etc/plugins/microservices/static_attributes.yaml
```
5. You may change the proxy URL (the value of BASE in
/opt/satosa/etc/proxy_conf.yaml), but it _must_ be a method plus
hostname without any trailing slash or path components, e.g.,
`https://proxy.example.com`, not `https://proxy.example.com/` nor
`https://proxy.example.com/satosa`. SATOSA must be hosted at the root
of your web site.
6. Comment out the `idp_blacklist_file` and `disco_srv` settings in
/opt/satosa/etc/plugins/backends/saml2_backend.yaml.
7. Generate IdP, SP, metadata signing, and web site keying material:
```sh
for i in frontend backend metadata https; do
openssl req -batch -x509 -nodes -days 3650 -newkey rsa:2048 \
-keyout /opt/satosa/etc/$i.key -out /opt/satosa/etc/$i.crt \
-subj /CN=proxy.example.com
done
```
8. Download the SAMLtest metadata.
```sh
curl https://samltest.id/saml/sp > /opt/satosa/etc/sp.xml
curl https://samltest.id/saml/idp > /opt/satosa/etc/idp.xml
```
9. Generate the proxy metadata. (How you do this changes in future
releases of SATOSA.)
```sh
. /opt/satosa/bin/activate
cd /opt/satosa/etc
satosa-saml-metadata proxy_conf.yaml metadata.key metadata.crt
--split-frontend --split-backend --dir /opt/satosa/etc
xmllint --format /opt/satosa/etc/Saml2IDP_0.xml >
/opt/satosa/etc/proxy-idp.xml
xmllint --format /opt/satosa/etc/Saml2_0.xml >
/opt/satosa/etc/proxy-sp.xml
```
10. Edit the proxy metadata files to remove the `<ns1:Signature>`
element, else SAMLtest will be unable to load them due to an invalid
signature.
11. Upload the proxy metadata to SAMLtest
(https://samltest.id/upload.php)
12. SAMLtest doesn't release the eduPerson Targeted ID attribute, so
you'll need to change the last three lines of
/opt/satosa/etc/internal_attributes.yaml to the following (and before
anyone says anything, NEVER USE AN EMAIL ADDRESS AS AN IDENTIFIER---this
is just a quick hack to get SATOSA working):
```
hash: [mail]
user_id_from_attrs: [mail]
user_id_to_attr: mail
```
13. Start SATOSA:
```sh
. /opt/satosa/bin/activate
cd /opt/satosa/etc
gunicorn -b0.0.0.0:443 --keyfile https.key --certfile https.crt
satosa.wsgi:app
```
14. At this point you should be able to perform an IdP test
(https://samltest.id/start-idp-test/) by specifying the entity ID of the
proxy's front end, e.g., https://example.com/Saml2IDP/proxy.xml. The
SAMLtest SP will request authentication by your proxy IdP, causing your
proxy SP to request authentication by the SAMLtest IdP. If everything
works right, you will end up back at the SAMLtest SP:
SAMLtest SP ---AuthnRequest---> SATOSA front end (IdP)/back end (SP)
---AuthnRequest---> SAMLtest IdP
SAMLtest SP <---AuthnResponse--- SATOSA front end (IdP)/back end (SP)
<---AuthnResponse--- SAMLtest IdP
I hope this helps other adopters. If you have any questions, please
reply on list so everyone can benefit from the discussion.
Best wishes,
Matthew
--
"The lyf so short, the craft so longe to lerne."
Hi Satosa Users List,
Firstly, I think my registration for this email list is still pending (or emails are being swallowed by a spam filter somewhere…) is anyone able to approve? Otherwise, maybe there’s simply no traffic :)
I’m hitting an issue when coming back from my discovery service (PyFF) to Satosa. At the point where Satosa looks up the IdP/SP in PyFF it fails with a bad SSL handshake. Satosa is running with Docker, as is PyFF.
Specific error:
requests.exceptions.SSLError: HTTPSConnectionPool(host='pyff.cern.ch<http://pyff.cern.ch>', port=443): Max retries exceeded with url: /entities/%7Bsha1%7Dbf0f1310cb092e88484def3c53613f8a10ebde3d (Caused by SSLError(SSLError("bad handshake: Error([('SSL routines', 'tls_process_server_certificate', 'certificate verify failed')],)",),))
I imagine this is because my PyFF instance is running with a certificate that is not publicly trusted. I’ve manually added the certificate to the SSL store in the Satosa docker container (and am able to connect with docker exec satosa_container openssl s_client -connect pyff.cern.ch:443<http://pyff.cern.ch:443> ), but am still hitting an exception in the Satosa code.
Has anyone come across this? Is there a way to specify additional trusted CAs, or request that the MDQ lookup be more lenient (for testing purposes)?
Cheers,
Hannah
Hello,
I’m wondering how I can assert Sirtfi for my Satosa SP proxy. Is there an example anywhere of how to assert the assurance profile and contact, or is it expected that this would be done by my federation registrar?
Thanks,
Hannah
Hi all,
I want to include a KeyDescriptor for use=encryption in the generated
SAML2 metadata. I'm talking about the
{host}/Saml2/proxy_saml2_backend.xml endpoint.
The following config works (i.e. SATOSA happily accepts encrypted
assertions), however the metadata endpoint does *not* include
use="encryption":
sp_config:
key_file: /etc/satosa/credentials/saml2backend.key
cert_file: /etc/satosa/credentials/saml2backend.crt
On the other hand, the following config does not work (i.e. SATOSA
throws an exception, once an encrypted assertion is received), however
the metadata endpoint *does* include use="encryption":
sp_config:
key_file: /etc/satosa/credentials/saml2backend.key
cert_file: /etc/satosa/credentials/saml2backend.crt
encryption_keypairs:
- key_file: /etc/satosa/credentials/saml2backend.key
cert_file: /etc/satosa/credentials/saml2backend.crt
I'm sure there's an easy solution. Anyone able to help?
Cheers,
David
