Dear all,
Is it possible to use a different discovery service depending on the SP
that sent a SAML AuthnRequest to SATOSA, or do I have to do that in the
discovery service's frontend somehow?
Best wishes,
Matthew
--
"The lyf so short, the craft so longe to lerne."
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."
I will have some SPs behind the proxy that need to use the refeds MFA profile via InCommon along with other SPs behind the same proxy that only require simple one-step password authentication. I’ve looked through the list archives and don’t see a solution to the problem I’m having.
I can verify by watching the browser saml flow that the SP is correctly requesting refeds mfa in RequestedAuthnContext. However, this request does not appear to be passed on to the selected IdP and the MFA authentication attribute is not set upon return.
There appears to be configuration available (acr_mapping) to specify what AuthnContextClassRef value satosa returns to the SP based on the selected IdP but that is not what we need for this application.
My question: is satosa supposed to pass the SP’s requested AuthnContext to the end user’s IdP and pass back the IdP’s response?
I’ll dig some more but am hoping that someone already knows how/if this should work in satosa.
Thanks much, Jim
Hi Satosa users,
I’m trying to add the Swiss eduPerson attributes [1] to the Satosa attribute maps [2] but running into problems when trying to use them. I’m running Satosa with Docker and have pulled the swiss attributes into .py files in the attributemaps folder, added them to my internal_attribute.yaml schema, restarted my container… however they don’t seem to be recognised.
==========================
The attribute coming from my IdP
==========================
<ns0:Attribute FriendlyName="swissEduPersonHomeOrganization" Name="urn:oid:2.16.756.1.2.5.1.1.4" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"><ns0:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xsi:type="xs:string">cern.ch</ns0:AttributeValue></ns0:Attribute>
====================================================
The config in internal_attribute.yaml (I just want to pass the attribute straight through to my Eps)
====================================================
swissedupersonhomeorganization:
saml: [swissEduPersonHomeOrganization]
==========================
Debug messages
==========================
"Unknown attribute name: <ns0:Attribute xmlns:ns0="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" FriendlyName="swissEduPersonHomeOrganization" Name="urn:oid:2.16.756.1.2.5.1.1.4" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"><ns0:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xsi:type="xs:string">cern.ch</ns0:AttributeValue></ns0:Attribute>”
...
"skipped backend attribute '['swissEduPersonHomeOrganization']': no value found”
The OID appears to be correct (SWISSEDUPERSON_OID = 'urn:oid:2.16.756.1.2.5.1.1.’, SWISSEDUPERSON_OID+’4' =‘swissEduPersonHomeOrganization’). Am I missing something? Some missing config or some cache somewhere?
Thanks in advance for any advice,
Hannah
[1] https://www.switch.ch/aai/docs/AAI_Attr_Specs.pdf
[2] https://github.com/IdentityPython/SATOSA/pull/270
Hi to everybody,
I'm doing fine with pyMultiLDAP as MS [3].
I can test multiple LDAP connections with received, aggregated and
rewritten data directly with pymultildap from command line, before move
configuration to deployed systems.
The same settings[1] used command line would be used in MS configuration,
as is.
I'm using multildap in satosa, in my pysaml2 Idp[2] and also as general
purpose LDAP proxy for SEARCH and BIND methods, with the help of slapd-sock.
At this moment I do not need too much parameters per SP in the MS
configuration but probably in the future I will. I preferred to delegate
data behaviour directly in multildap.settings instead of MS configuration.
I share as it come,
regards
[1]
https://github.com/peppelinux/pyMultiLDAP/blob/master/examples/settings.py.…
<https://github.com/peppelinux/pyMultiLDAP/blob/master/examples/settings.py.…>
[2] https://uniauth.readthedocs.io/en/latest/index.html
[3]
https://github.com/peppelinux/pyMultiLDAP/tree/fe602e39240d6a3240f09c852cb6…
--
____________________
Dott. Giuseppe De Marco
CENTRO ICT DI ATENEO
University of Calabria
87036 Rende (CS) - Italy
Phone: +39 0984 496961
e-mail: giuseppe.demarco at unical.it
