Dear all,
I am currently trying to set up a saml2-saml2 proxy and have come to an
impasse: It seems that I have incorrectly/incompletely set up the
frontend. When trying to log in satosa logs "configuration error:
unknown system entity <entityID of SP>". I thought the entityID would be
set in the frontend plugin configuration through
config.idp_config.metadata.local = <file containing SP metadata>. Do I
have to set the SP entityID somewhere else?
Thank you for your help!
Best regards,
Jonas Schwab
I am writing to request assistance with releasing a custom attribute that is not listed as a requested attribute by one of our InCommon Service Providers (SPs). The attribute is present in the IDP response, but it appears that it is not being returned to the InCommon SP.
I have attempted to set the attribute as default for all SPs, but I would like to limit its release to specific SP if needed.
I have made some changes to the configuration files and observed the following log messages:
Filter: ['edupersonprincipalname', 'edupersonaffiliation', 'givenname', 'edupersonscopedaffiliation', 'mail', 'edupersontargetedid']
Attribute Statement: <ns0:AttributeStatement xmlns:ns0="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><ns0:Attribute FriendlyName="mail" Name="urn:oid:0.9.2342.19200300.100.1.3" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
<ns0:Attribute FriendlyName="abcID" Name="urn:oid:1.3.6.1.4.18941.1.2.1.1" 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">8989898</ns0:AttributeValue></ns0:Attribute>
<ns0:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">99999</ns0:NameID></ns0:AttributeValue></ns0:Attribute></ns0:AttributeStatement>
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="abcID" Name="urn:oid:1.3.6.1.4.18941.1.2.1.1" 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">8989898</ns0:AttributeValue></ns0:Attribute>
skipped backend attribute ['abcID']: no value found
I have made the following changes to the configuration files:
Internal_attributes.yaml
Added
abcid:
saml: [abcID]
Backend.yaml
Added
custom_attribute_release:
"default":
include: ["abcID"]
allow_unknown_attributes: true
attribute_map_dir: [/etc/satosa/attributemaps]
Frontend.yaml
-No specific changes made
Saml_url.py
From area:
'urn:oid:1.3.6.1.4.18941.1.2.1.1': 'abcID',
To area:
'abcID': 'urn:oid:1.3.6.1.4.18941.1.2.1.1',
Could you please help me troubleshoot this issue and provide guidance on how to release the custom attribute as needed?
Also how could I release this attribute as the NameID for just the specific SP that requires it?
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 all,
Apologies for casting a wide net with this communication; I wanted to
ensure I reached the people most interested in this information.
There have recently been several meetings to re-engage the community on
IdPY work. We invite you to attend an *IdPY Town Hall* where we will share
what has been discussed (this meeting will be recorded):
*IdPY TOWN HALL MEETING*
17 June 2026
6:00 AM (San Francisco) | 9:00 AM (New York) | 14:00 (London) | 11:00 PM
(Sydney)
*(No advanced registration required)*
https://us06web.zoom.us/j/83349546274?pwd=Hxk7X9wIct6HTXlVmI5yuXmVdwJOXa.1
ADD THIS EVENT TO YOUR CALENDAR: https://www.addevent.com/event/qtmlhpw6jx87
---
*[optional] TECHNICAL TEAM MEETINGS*
Additionally, if you are interested in the technical work to develop IdPY
tools, we will hold a re-kickoff meeting to plan the next 6 months of work
and decide on a day/time and pace for ongoing meetings.
Indicate your availability on the following poll if you would like to be
involved, even if you can't attend this time. Everyone who responds will be
added to future technical team communications.
Poll to schedule the IdPY Technical Re-kickoff Meeting during the week of 1
June:
https://doodle.com/group-poll/participate/bYYKA5Ob
Please reach out to me if you need any additional information. Looking
forward to seeing you there.
Best, Laura Paglione
