12:40 p.m.
Hi all,
Is there an existing implementation (or planned) implementation of the
new SAML subject identifiers [1] ?
[1]
https://docs.oasis-open.org/security/saml-subject-id-attr/v1.0/saml-subject…
Many thanks,
Niels
--
Niels van Dijk Technical Product Manager Trust & Security
Mob: +31 651347657 | Skype: cdr-80 | PGP Key ID: 0xDE7BB2F5
SURFnet BV | PO.Box 19035 | NL-3501 DA Utrecht | The Netherlands
www.surfnet.nl www.openconext.org
12:49 p.m.
I wrote a microservice which generates pairwise-id from an incoming eduPersonTargetedID:
https://github.com/alexstuart/pairwise_generation
It was used for a specific project & is targeted at a specific version of SATOSA.
I'm happy to be involved making it more widely applicable.
Alex
________________________________________
From: Satosa-dev <satosa-dev-bounces at lists.sunet.se> on behalf of Niels van Dijk
<niels.vandijk at surfnet.nl>
Sent: 03 March 2020 12:40
To: satosa-dev at lists.sunet.se
Subject: [Satosa-dev] SaToSa support for new SAML subject identifiers
Hi all,
Is there an existing implementation (or planned) implementation of the
new SAML subject identifiers [1] ?
[1]
https://docs.oasis-open.org/security/saml-subject-id-attr/v1.0/saml-subject…
Many thanks,
Niels
--
Niels van Dijk Technical Product Manager Trust & Security
Mob: +31 651347657 | Skype: cdr-80 | PGP Key ID: 0xDE7BB2F5
SURFnet BV | PO.Box 19035 | NL-3501 DA Utrecht | The Netherlands
www.surfnet.nl www.openconext.org
Jisc is a registered charity (number 1149740) and a company limited by guarantee which is
registered in England under company number. 05747339, VAT number GB 197 0632 86. Jisc’s
registered office is: 4 Portwall Lane, Bristol, BS1 6NB. 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 02881024, VAT number GB 197 0632 86.
The registered office is: 4 Portwall Lane, Bristol, BS1 6NB. T 0203 697 5800.
For more details on how Jisc handles your data see our privacy notice here:
https://www.jisc.ac.uk/website/privacy-notice
1:28 p.m.
Hi Alex,
Cool! This should be integrated as a core MS I think
this deserves a star
Il giorno mar 3 mar 2020 alle ore 13:49 Alex Stuart <Alex.Stuart at jisc.ac.uk>
ha scritto:
I wrote a microservice which generates pairwise-id
from an incoming
eduPersonTargetedID: https://github.com/alexstuart/pairwise_generation
It was used for a specific project & is targeted at a specific version of
SATOSA. I'm happy to be involved making it more widely applicable.
Alex
________________________________________
From: Satosa-dev <satosa-dev-bounces at lists.sunet.se> on behalf of Niels
van Dijk <niels.vandijk at surfnet.nl>
Sent: 03 March 2020 12:40
To: satosa-dev at lists.sunet.se
Subject: [Satosa-dev] SaToSa support for new SAML subject identifiers
Hi all,
Is there an existing implementation (or planned) implementation of the
new SAML subject identifiers [1] ?
[1]
https://docs.oasis-open.org/security/saml-subject-id-attr/v1.0/saml-subject…
Many thanks,
Niels
--
Niels van Dijk Technical Product Manager Trust & Security
Mob: +31 651347657 | Skype: cdr-80 | PGP Key ID: 0xDE7BB2F5
SURFnet BV | PO.Box 19035 | NL-3501 DA Utrecht | The Netherlands
www.surfnet.nl www.openconext.org
Jisc is a registered charity (number 1149740) and a company limited by
guarantee which is registered in England under company number. 05747339,
VAT number GB 197 0632 86. Jisc’s registered office is: 4 Portwall Lane,
Bristol, BS1 6NB. 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
02881024, VAT number GB 197 0632 86. The registered office is: 4 Portwall
Lane, Bristol, BS1 6NB. T 0203 697 5800.
For more details on how Jisc handles your data see our privacy notice
here: https://www.jisc.ac.uk/website/privacy-notice
_______________________________________________
Satosa-dev mailing list
Satosa-dev at lists.sunet.se
https://lists.sunet.se/listinfo/satosa-dev
--
____________________
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
1:29 p.m.
Hello Niels,
On Tue, 3 Mar 2020 at 14:40, Niels van Dijk <niels.vandijk at surfnet.nl> wrote:
Hi all,
Is there an existing implementation (or planned) implementation of the
new SAML subject identifiers [1] ?
I am not sure what it is that you are looking for in satosa. The
satosa core does not know anything about protocols. The new subject-id
is a SAML concept. PySAML2 can recognise it (see
https://github.com/IdentityPython/pysaml2/commit/6d611b715ca11b2f8250024ba6…).
Having said this, the new identifier takes the form of an attribute.
This means that the saml frontend and backend will translate it to
satosa's internal structure as a key-value under the internal-data
attribute structure (`internal_data.attributes["subject-id"]` and
`internal_data.attributes["pairwise-id"]` will contain the
corresponding values; if those were received).
Same goes for the internal_attributes.yaml configuration, where you
can map to which internal name and claim or SAML-attribute you want to
map the value. You do this by a configuration like so
```
attributes:
identifier:
openid: [sub]
saml: ["subject-id"]
...
```
I hope this helps.
Cheers,
--
Ivan c00kiemon5ter Kanakarakis >:3
4:09 p.m.
Hi Alex, Ivan,
Many thanks for your thoughts and suggestion so far.
You have I think addressed 2 out of my 4 concerns in this regard:
1) First of all with the comments below from Ivan, we could indeed
either create relevant configuration for accepting 'incoming' SAML based
subject id attributes and how these get mapped internally. Seems
straightforward at first glance, perhaps a bit of thought is needed to
identify if incoming IDs should be passed on directly into the sub or
should be reissued. The same goes for the reverse scenario where a sub
is incoming and needs to be transformed into the equivalent SAML attribute
I think it would be nice to perhaps provide example configuration that
shows how to set that up.
2) For reissue, I think Alex's work fits in nicely, haven't tested that
yet though, but many thanks for the pointer.
3) When SaToSa acts as a SAML entity, the use of subject identifiers
required some additional metadata statements. like e.g.:
<mdattr:EntityAttributes>
<saml:Attribute Name="urn:oasis:names:tc:SAML:profiles:subject-id:req"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
<saml:AttributeValue>any</saml:AttributeValue>
</saml:Attribute>
</mdattr:EntityAttributes>
We need to see if this is supported and (assuing it is) it would be nice
to provide a config example again.
4) As we can probably not just drop support for other incoming
identifier SAML attributes, some of us may need to update their business
login to select the properer identifier to use depending on what the IdP
is sending. Given that this will be a common theme for the many years we
have both old identifier attributes and the new subject identifiers, I
guess it would make sense to provide some default config or code for
that as well?
Best,
Niels
On 03-03-2020 14:29, Ivan Kanakarakis wrote:
Hello Niels,
On Tue, 3 Mar 2020 at 14:40, Niels van Dijk <niels.vandijk at surfnet.nl> wrote:
--
Niels van Dijk Technical Product Manager Trust & Security
Mob: +31 651347657 | Skype: cdr-80 | PGP Key ID: 0xDE7BB2F5
SURFnet BV | PO.Box 19035 | NL-3501 DA Utrecht | The Netherlands
www.surfnet.nl www.openconext.org
Hi all,
Is there an existing implementation (or planned) implementation of the
new SAML subject identifiers [1] ?
I am not sure what it is that you are looking for in satosa. The
satosa core does not know anything about protocols. The new subject-id
is a SAML concept. PySAML2 can recognise it (see
https://github.com/IdentityPython/pysaml2/commit/6d611b715ca11b2f8250024ba6…).
Having said this, the new identifier takes the form of an attribute.
This means that the saml frontend and backend will translate it to
satosa's internal structure as a key-value under the internal-data
attribute structure (`internal_data.attributes["subject-id"]` and
`internal_data.attributes["pairwise-id"]` will contain the
corresponding values; if those were received).
Same goes for the internal_attributes.yaml configuration, where you
can map to which internal name and claim or SAML-attribute you want to
map the value. You do this by a configuration like so
```
attributes:
identifier:
openid: [sub]
saml: ["subject-id"]
...
```
I hope this helps.
Cheers,
9:06 p.m.
Hi Niels,
2) For reissue, I think Alex's work fits in nicely, haven't tested that yet
though, but many thanks for the pointer.
Thanks, but the microservice quite rough & I don't know Satosa well:
- The scope is hardcoded and I needed to manually ensure the it matched the scope in
metadata.
- I'm not aware of attribute encoders in Satosa (like the Shibboleth IdP's,
https://wiki.shibboleth.net/confluence/display/IDP30/AttributeEncoderPlugin…)
so I wrote the data manipulation within the class.
- I was confident that I'd receive eduPersonTargetedID for the lifetime of the project
so pairwise-id is constructed directly from eduPersonTargetedID, and I didn't need to
handle the mapping you describe in (4). To manage the migration from one incoming
identifier to another, I presume that proxies would need to generate the pairwise-id from
an intermediate attribute, and store a many-to-one mapping from the incoming attributes to
that intermediate attribute. I seem to recall there were a couple of massive threads on
this about a year ago on the REFEDS list ...
Regards,
Alex
4) As we can probably not just drop support for other
incoming identifier SAML attributes, some of us may need to update their business login to
select the properer identifier to use depending on what the IdP is sending. Given that
this will be a common theme for the many years we have both old identifier attributes and
the new subject identifiers, I guess it would make sense to provide some default config or
code for that as well?
Best,
Niels
On 03-03-2020 14:29, Ivan Kanakarakis wrote:
—
Alex Stuart, Technical Development Manager (Trust and Identity)
alex.stuart at jisc.ac.uk
Hello Niels,
On Tue, 3 Mar 2020 at 14:40, Niels van Dijk
<niels.vandijk at surfnet.nl>
wrote:
--
Niels van Dijk Technical Product Manager Trust & Security
Mob: +31 651347657 | Skype: cdr-80 | PGP Key ID: 0xDE7BB2F5
SURFnet BV | PO.Box 19035 | NL-3501 DA Utrecht | The Netherlands
www.surfnet.nl www.openconext.org Hi all,
Is there an existing implementation (or planned) implementation of the
new SAML subject identifiers [1] ?
I am not sure what it is that you are looking for in satosa. The
satosa core does not know anything about protocols. The new subject-id
is a SAML concept. PySAML2 can recognise it (see
https://github.com/IdentityPython/pysaml2/commit/6d611b715ca11b2f8250024ba6…
).
Having said this, the new identifier takes the form of an attribute.
This means that the saml frontend and backend will translate it to
satosa's internal structure as a key-value under the internal-data
attribute structure (`internal_data.attributes["subject-id"]` and
`internal_data.attributes["pairwise-id"]` will contain the
corresponding values; if those were received).
Same goes for the internal_attributes.yaml configuration, where you
can map to which internal name and claim or SAML-attribute you want to
map the value. You do this by a configuration like so
```
attributes:
identifier:
openid: [sub]
saml: ["subject-id"]
...
```
I hope this helps.
Cheers,
8:38 a.m.
Hi Alex,
Thanks for the heads-up. Based on what you write it might indeed need a
bit more work, but for sure we can draw some inspiration form your code ;)
thx,
Niels
On 03-03-2020 22:06, Alex Stuart wrote:
Hi Niels,
--
Niels van Dijk Technical Product Manager Trust & Security
Mob: +31 651347657 | Skype: cdr-80 | PGP Key ID: 0xDE7BB2F5
SURFnet BV | PO.Box 19035 | NL-3501 DA Utrecht | The Netherlands
www.surfnet.nl www.openconext.org
2) For reissue, I think Alex's work fits in
nicely, haven't tested that yet though, but many thanks for the pointer.
Thanks, but the microservice quite rough & I don't know Satosa well:
- The scope is hardcoded and I needed to manually ensure the it matched the scope in
metadata.
- I'm not aware of attribute encoders in Satosa (like the Shibboleth IdP's,
https://wiki.shibboleth.net/confluence/display/IDP30/AttributeEncoderPlugin…)
so I wrote the data manipulation within the class.
- I was confident that I'd receive eduPersonTargetedID for the lifetime of the
project so pairwise-id is constructed directly from eduPersonTargetedID, and I didn't
need to handle the mapping you describe in (4). To manage the migration from one incoming
identifier to another, I presume that proxies would need to generate the pairwise-id from
an intermediate attribute, and store a many-to-one mapping from the incoming attributes to
that intermediate attribute. I seem to recall there were a couple of massive threads on
this about a year ago on the REFEDS list ...
Regards,
Alex
4) As we can probably not just drop support for
other incoming identifier SAML attributes, some of us may need to update their business
login to select the properer identifier to use depending on what the IdP is sending. Given
that this will be a common theme for the many years we have both old identifier attributes
and the new subject identifiers, I guess it would make sense to provide some default
config or code for that as well?
Best,
Niels
On 03-03-2020 14:29, Ivan Kanakarakis wrote:
—
Alex Stuart, Technical Development Manager (Trust and Identity)
alex.stuart at jisc.ac.uk
Hello Niels,
On Tue, 3 Mar 2020 at 14:40, Niels van Dijk
<niels.vandijk at surfnet.nl>
wrote:
--
Niels van Dijk Technical Product Manager Trust & Security
Mob: +31 651347657 | Skype: cdr-80 | PGP Key ID: 0xDE7BB2F5
SURFnet BV | PO.Box 19035 | NL-3501 DA Utrecht | The Netherlands
www.surfnet.nl www.openconext.org Hi all,
Is there an existing implementation (or planned) implementation of the
new SAML subject identifiers [1] ?
I am not sure what it is that you are looking for in satosa. The
satosa core does not know anything about protocols. The new subject-id
is a SAML concept. PySAML2 can recognise it (see
https://github.com/IdentityPython/pysaml2/commit/6d611b715ca11b2f8250024ba6…
).
Having said this, the new identifier takes the form of an attribute.
This means that the saml frontend and backend will translate it to
satosa's internal structure as a key-value under the internal-data
attribute structure (`internal_data.attributes["subject-id"]` and
`internal_data.attributes["pairwise-id"]` will contain the
corresponding values; if those were received).
Same goes for the internal_attributes.yaml configuration, where you
can map to which internal name and claim or SAML-attribute you want to
map the value. You do this by a configuration like so
```
attributes:
identifier:
openid: [sub]
saml: ["subject-id"]
...
```
I hope this helps.
Cheers,
1536
days inactive
1537
days old
6 comments
4 participants
participants (4)
-
Alex.Stuart＠jisc.ac.uk -
giuseppe.demarco＠unical.it -
ivan.kanak＠gmail.com -
niels.vandijk＠surfnet.nl