4:05 p.m.
Hi,
Is there a place yet for contributed microservices?
I ask because I have written a microservice I am calling
"PrimaryIdentifier" for the NIAID use case.
An example configuration might look like this:
module: primary_identifier.PrimaryIdentifier
name: PrimaryIdentifier
config:
idp_identifiers:
- epuid
-
- eppn
- name_id: urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
-
- eppn
- edupersontargetedid
- eppn
-
- name_id: urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
- issuer
-
- edupersontargetedid
- issuer
clear_input_attributes: no
primary_identifier: uid
on_error:
https://registration.scienceforum.sc/registry/collaboration_error/co_collab…
With this configuration the microservice will examine the attributes
asserted by a campus/organization IdP and look in the following order
for a value to use as the primary identifier:
1) eduPersonUniqueId
2) eduPersonPrincipalName and SAML2 persistent NameID, in case the IdP
is signaling it reassigns eduPersonPrincipalName
3) eduPersonPrincipalName and eduPersonTargetedId, in case the IdP is
signaling it reassigns eduPersonPrincipalName
4) eduPersonPrincipalName
5) SAML2 persistent NameID
6) eduPersonTargetedId
The special identifier 'issuer' signals that any value found is to be
"scoped" with the entityID of the IdP.
When it finds the first value it can use from that search order it then
asserts that value as 'uid' to the SP.
If no value is found after the configured search order then since
'on_error' is set it will redirect the browser to an "error" service to
handle that error.
Right now we are planning on using a custom COmanage Registry plugin to
"catch" the error and display instructions to the user.
I am wondering if any other project might have use for the microservice?
Any other thoughts?
Thanks,
Scott K
4:56 a.m.
Skickat från min iPhone
14 juli 2017 kl. 18:05 skrev Scott Koranda
<skoranda at gmail.com>:
Hi,
Is there a place yet for contributed microservices?
Nobody has gotten around to doing the split yet...
I ask because I have written a microservice I am
calling
"PrimaryIdentifier" for the NIAID use case.
An example configuration might look like this:
module: primary_identifier.PrimaryIdentifier
name: PrimaryIdentifier
config:
idp_identifiers:
- epuid
-
- eppn
- name_id: urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
-
- eppn
- edupersontargetedid
- eppn
-
- name_id: urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
- issuer
-
- edupersontargetedid
- issuer
clear_input_attributes: no
primary_identifier: uid
on_error:
https://registration.scienceforum.sc/registry/collaboration_error/co_collab…
With this configuration the microservice will examine the attributes
asserted by a campus/organization IdP and look in the following order
for a value to use as the primary identifier:
1) eduPersonUniqueId
2) eduPersonPrincipalName and SAML2 persistent NameID, in case the IdP
is signaling it reassigns eduPersonPrincipalName
3) eduPersonPrincipalName and eduPersonTargetedId, in case the IdP is
signaling it reassigns eduPersonPrincipalName
4) eduPersonPrincipalName
5) SAML2 persistent NameID
6) eduPersonTargetedId
The special identifier 'issuer' signals that any value found is to be
"scoped" with the entityID of the IdP.
When it finds the first value it can use from that search order it then
asserts that value as 'uid' to the SP.
If no value is found after the configured search order then since
'on_error' is set it will redirect the browser to an "error" service to
handle that error.
Right now we are planning on using a custom COmanage Registry plugin to
"catch" the error and display instructions to the user.
I am wondering if any other project might have use for the microservice?
Any other thoughts?
Thanks,
Scott K
_______________________________________________
Satosa-dev mailing list
Satosa-dev at lists.sunet.se
https://lists.sunet.se/listinfo/satosa-dev
7:13 a.m.
On 15/07/2017 07:56 πμ, Leif Johansson wrote:
--
------------------------------------------------------------------
Ioannis Kakavas - ikakavas at grnet.gr
Identity and Security Engineer
GRNET Network Operations Centre
Greek Research & Technology Network - http://www.grnet.gr
7, Kifisias Av. 115 23 Athens, Greece
Office: +30 2107474255
PGP Fingerprint: A5AA FB5E 740A 603B FAB1 9920 D70F 0CD5 9DE3 C262
------------------------------------------------------------------
Skickat från min iPhone
It was assigned to me during TNC meeting but work got in the way. I hope
I can have this finished within July
14 juli 2017 kl. 18:05 skrev Scott Koranda
<skoranda at gmail.com>:
Hi,
Is there a place yet for contributed microservices?
Nobody has gotten around to doing the split yet... I ask because I have written a microservice I am
calling
"PrimaryIdentifier" for the NIAID use case.
An example configuration might look like this:
module: primary_identifier.PrimaryIdentifier
name: PrimaryIdentifier
config:
idp_identifiers:
- epuid
-
- eppn
- name_id: urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
-
- eppn
- edupersontargetedid
- eppn
-
- name_id: urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
- issuer
-
- edupersontargetedid
- issuer
clear_input_attributes: no
primary_identifier: uid
on_error:
https://registration.scienceforum.sc/registry/collaboration_error/co_collab…
With this configuration the microservice will examine the attributes
asserted by a campus/organization IdP and look in the following order
for a value to use as the primary identifier:
1) eduPersonUniqueId
2) eduPersonPrincipalName and SAML2 persistent NameID, in case the IdP
is signaling it reassigns eduPersonPrincipalName
3) eduPersonPrincipalName and eduPersonTargetedId, in case the IdP is
signaling it reassigns eduPersonPrincipalName
4) eduPersonPrincipalName
5) SAML2 persistent NameID
6) eduPersonTargetedId
The special identifier 'issuer' signals that any value found is to be
"scoped" with the entityID of the IdP.
When it finds the first value it can use from that search order it then
asserts that value as 'uid' to the SP.
If no value is found after the configured search order then since
'on_error' is set it will redirect the browser to an "error" service to
handle that error.
Right now we are planning on using a custom COmanage Registry plugin to
"catch" the error and display instructions to the user.
I am wondering if any other project might have use for the microservice?
Any other thoughts?
Thanks,
Scott K
_______________________________________________
Satosa-dev mailing list
Satosa-dev at lists.sunet.se
https://lists.sunet.se/listinfo/satosa-dev
_______________________________________________
Satosa-dev mailing list
Satosa-dev at lists.sunet.se
https://lists.sunet.se/listinfo/satosa-dev
7:20 a.m.
Skickat från min iPhone
--
------------------------------------------------------------------
Ioannis Kakavas - ikakavas at grnet.gr
Identity and Security Engineer
GRNET Network Operations Centre
Greek Research & Technology Network - http://www.grnet.gr
7, Kifisias Av. 115 23 Athens, Greece
Office: +30 2107474255
PGP Fingerprint: A5AA FB5E 740A 603B FAB1 9920 D70F 0CD5 9DE3 C262
------------------------------------------------------------------
_______________________________________________
Satosa-dev mailing list
Satosa-dev at lists.sunet.se
https://lists.sunet.se/listinfo/satosa-dev
17 juli 2017 kl. 09:13 skrev Ioannis Kakavas
<ikakavas at noc.grnet.gr>:
I didn't know we assigned a stuckee - great if you have time to do it though!
On 15/07/2017 07:56 πμ, Leif Johansson wrote:
Skickat från min iPhone
It was assigned to me during TNC meeting but work got in the way. I hope
I can have this finished within July 14 juli 2017 kl. 18:05 skrev Scott Koranda
<skoranda at gmail.com>:
Hi,
Is there a place yet for contributed microservices?
Nobody has gotten around to doing the split yet... I ask because I have written a microservice I am
calling
"PrimaryIdentifier" for the NIAID use case.
An example configuration might look like this:
module: primary_identifier.PrimaryIdentifier
name: PrimaryIdentifier
config:
idp_identifiers:
- epuid
-
- eppn
- name_id: urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
-
- eppn
- edupersontargetedid
- eppn
-
- name_id: urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
- issuer
-
- edupersontargetedid
- issuer
clear_input_attributes: no
primary_identifier: uid
on_error:
https://registration.scienceforum.sc/registry/collaboration_error/co_collab…
With this configuration the microservice will examine the attributes
asserted by a campus/organization IdP and look in the following order
for a value to use as the primary identifier:
1) eduPersonUniqueId
2) eduPersonPrincipalName and SAML2 persistent NameID, in case the IdP
is signaling it reassigns eduPersonPrincipalName
3) eduPersonPrincipalName and eduPersonTargetedId, in case the IdP is
signaling it reassigns eduPersonPrincipalName
4) eduPersonPrincipalName
5) SAML2 persistent NameID
6) eduPersonTargetedId
The special identifier 'issuer' signals that any value found is to be
"scoped" with the entityID of the IdP.
When it finds the first value it can use from that search order it then
asserts that value as 'uid' to the SP.
If no value is found after the configured search order then since
'on_error' is set it will redirect the browser to an "error" service to
handle that error.
Right now we are planning on using a custom COmanage Registry plugin to
"catch" the error and display instructions to the user.
I am wondering if any other project might have use for the microservice?
Any other thoughts?
Thanks,
Scott K
_______________________________________________
Satosa-dev mailing list
Satosa-dev at lists.sunet.se
https://lists.sunet.se/listinfo/satosa-dev
_______________________________________________
Satosa-dev mailing list
Satosa-dev at lists.sunet.se
https://lists.sunet.se/listinfo/satosa-dev
1:03 p.m.
Hello Scott,
module: primary_identifier.PrimaryIdentifier
name: PrimaryIdentifier
config:
idp_identifiers:
- epuid
-
- eppn
- name_id: urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
-
- eppn
- edupersontargetedid
- eppn
-
- name_id: urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
- issuer
-
- edupersontargetedid
- issuer
clear_input_attributes: no
primary_identifier: uid
on_error:
https://registration.scienceforum.sc/registry/collaboration_error/co_collab…
idp_identifiers defines an array of internal attributes to be looked
up. If one has no name then the service should look for a subarray
which is expected to have multiple items defining some dependent
behaviour.
With this configuration the microservice will examine
the attributes
asserted by a campus/organization IdP and look in the following order
for a value to use as the primary identifier:
I am not sure I understand the search conditions. Here is what I get:
1) eduPersonUniqueId
You try to assign uid by epuid. If epuid has no value you skip it and
proceed to the next item.
2) eduPersonPrincipalName and SAML2 persistent NameID,
in case the IdP
is signaling it reassigns eduPersonPrincipalName
The second item has no name, so you grab the subarray and now you know
you need to look up eppn. If eppn has no value it is assigned the
value from name_id(?) and that value is used. If both eppn and name_id
are empty you continue to the next item.
3) eduPersonPrincipalName and eduPersonTargetedId, in
case the IdP is
signaling it reassigns eduPersonPrincipalName
Again this item has no name, so you look up eppn. If it is empty
(which must be, otherwise the search would have stopped on the
previous item) it gets a value from eptid. If both are empty we skip
to the next item.
4) eduPersonPrincipalName
eppn should be empty otherwise search would have stopped on step 2
5) SAML2 persistent NameID
name_id should be empty otherwise search would have stopped on step 2
6) eduPersonTargetedId
eptid should be empty otherwise search would have stopped on step 3
I am not sure I understand correctly. Could you please elaborate?
The special identifier 'issuer' signals that
any value found is to be
"scoped" with the entityID of the IdP.
I do not really like the configuration format. By reading it one has
no idea what is going on, unless one knows the internals. I would
propose to convert the format to key-value pairs where the key has a
clear name that denotes the behaviour.
In the same sense I would say that 'issuer' should not be value, but a
key on the object it needs to place the scope. Something like:
- attribute: name_id
scope: true # or
scope: 'scope_value'
When it finds the first value it can use from that
search order it then
asserts that value as 'uid' to the SP.
'uid' (as set by the 'primary_identifier ') is an internal attribute,
right?
If no value is found after the configured search order
then since
'on_error' is set it will redirect the browser to an "error" service to
handle that error.
that's a nice idea, delegating errors on a different service, as
satosa is not very flexible as to what to present in case of an error
I am wondering if any other project might have use for
the microservice?
Any other thoughts?
I do not really have a use case in my mind, but the way I see what
you're trying to do is, as a fallback mechanism for an attribute to
get a value. Attribute mapping does that but with less flexibility (ie
no special conditions with name_id, no error handling etc). I was
thinking if this can be implemented using the AttributeProcessor
service that was merged lately (but I need to understand the
requirements first).
Kind regards,
--
Ivan Kanakarakis
12:37 p.m.
Hi Ivan,
Thank you for the feedback. I truly appreciate it.
Please see inline below for comments and other follow up.
It is an ordered list.
So in Python it would be
[
'epuid',
['eppn',
'name_id:urn:oasis:names:tc:SAML:2.0:nameid-format:persistent'],
['eppn', 'edupersontargetedid'],
'eppn',
['name_id:
urn:oasis:names:tc:SAML:2.0:nameid-format:persistent','issuer'],
['edupersontargetedid', 'issuer']
]
<snip>
I do not either. I am glad you said so.
I think it is the best approach and will allow SATOSA to focus on doing
fewer things well.
But it does suggest we will want some type of "standard" for
communicating the errors from SATOSA to the other service.
Right now I am just redirecting the browser to the error service with a
query string that includes the SP and IdP entityIDs so we can track
which SPs users were trying to access and which IdPs did not give us
anything we can use as an identifier.
I am not particularly happy with that either but I need something right
now and hope that some type of "standard" could evolve.
I don't think of it that way.
I think of it as the only approach to be able to uniquely identify a
user for a VO that federates widely across eduGAIN where the practice of
what attributes an IdP will assert varies across the entire spectrum.
Let me put it a different way to the list: if your SATOSA proxy is
federating with IdPs from InCommon, most EU countries, Japan, Australia,
Chile, and India, how do you make sure that you uniquely identify each
user so that a simple SP behind the proxy can just look at $REMOTE_USER?
Given the definition of the R&S entity category and that IdPs do
re-assign ePPN, as well as the realities of IdPs only sending a targeted
identifier sometimes, I don't see any way to do this other than use the
ordered list I am proposing?
module:
primary_identifier.PrimaryIdentifier
name: PrimaryIdentifier
config:
idp_identifiers:
- epuid
-
- eppn
- name_id: urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
-
- eppn
- edupersontargetedid
- eppn
-
- name_id: urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
- issuer
-
- edupersontargetedid
- issuer
clear_input_attributes: no
primary_identifier: uid
on_error:
https://registration.scienceforum.sc/registry/collaboration_error/co_collab…
idp_identifiers defines an array of internal attributes to be looked
up. If one has no name then the service should look for a subarray
which is expected to have multiple items defining some dependent
behaviour.
For example, the second element in the list is
['eppn', 'name_id:urn:oasis:names:tc:SAML:2.0:nameid-format:persistent']
which means that the combination of eduPersonPrincipalName and SAML2
persistent NameID would be the identifier.
The list specifies the ordered preference.
We prefer
['eppn', 'name_id:urn:oasis:names:tc:SAML:2.0:nameid-format:persistent']
over just
'eppn'
for example because if an IdP asserts both then we have to assume the
IdP is signalling that it re-assigns eduPersonPrincipalName and we must
use both to construct the primary identifier.
With this
configuration the microservice will examine the attributes
asserted by a campus/organization IdP and look in the following order
for a value to use as the primary identifier:
I am not sure I understand the search conditions. Here is what I get:
I am not sure I understand correctly. Could you please
elaborate?
The list specifies the preferred ordering or ranking, not the logic or
algorithm of how the microservice actually examines the attributes that
the IdP asserts.
The list is just stating that eduPersonUniqueId is preferred first, then
the combination of eduPersonPrincipalName and SAML2 persistent NameID,
and so on.
The special
identifier 'issuer' signals that any value found is to be
"scoped" with the entityID of the IdP.
I do not really like the configuration format. By reading it one has
no idea what is going on, unless one knows the internals. I would
propose to convert the format to key-value pairs where the key has a
clear name that denotes the behaviour.
If you have time and the inclination can you provide an example of what
you suggest?
In the same sense I would say that 'issuer'
should not be value, but a
key on the object it needs to place the scope. Something like:
- attribute: name_id
scope: true # or
scope: 'scope_value'
Hmmmm. Thanks. I will put some thought into that.
When it finds
the first value it can use from that search order it then
asserts that value as 'uid' to the SP.
'uid' (as set by the 'primary_identifier
') is an internal attribute,
right?
Correct.
If no value is
found after the configured search order then since
'on_error' is set it will redirect the browser to an "error" service to
handle that error.
that's a nice idea, delegating errors on a different service, as
satosa is not very flexible as to what to present in case of an error I am wondering
if any other project might have use for the microservice?
Any other thoughts?
I do not really have a use case in my mind, but the way I see what
you're trying to do is, as a fallback mechanism for an attribute to
get a value. Attribute mapping does that but with less flexibility
(ie
no special conditions with name_id, no error handling etc). I was
thinking if this can be implemented using the AttributeProcessor
service that was merged lately (but I need to understand the
requirements first).
Thanks. I will look at that in more detail.
Thanks again for the dialogue.
Cheers,
Scott K
4:10 p.m.
Hi Scott,
yes, I agree - this needs some thinking.
I don't think of it that way.
I think of it as the only approach to be able to uniquely identify a
user for a VO that federates widely across eduGAIN where the practice of
what attributes an IdP will assert varies across the entire spectrum.
Let me put it a different way to the list: if your SATOSA proxy is
federating with IdPs from InCommon, most EU countries, Japan, Australia,
Chile, and India, how do you make sure that you uniquely identify each
user so that a simple SP behind the proxy can just look at $REMOTE_USER?
Given the definition of the R&S entity category and that IdPs do
re-assign ePPN, as well as the realities of IdPs only sending a targeted
identifier sometimes, I don't see any way to do this other than use the
ordered list I am proposing?
alright, I can see the reasoning, but the mechanism is a fallback list
I tried that now that I get the bigger picture and this is the
processor I came up with:
https://gist.github.com/c00kiemon5ter/4f0a46d750b3b612373d3f97b1024547
Feel free to use/copy whatever you like.
Cheers,
--
Ivan Kanakarakis
For example, the second element in the list is
['eppn', 'name_id:urn:oasis:names:tc:SAML:2.0:nameid-format:persistent']
which means that the combination of eduPersonPrincipalName and SAML2
persistent NameID would be the identifier.
alright, this makes much more sense now.
that's a
nice idea, delegating errors on a different service, as
satosa is not very flexible as to what to present in case of an error
I think it is the best approach and will allow SATOSA to focus on doing
fewer things well.
But it does suggest we will want some type of "standard" for
communicating the errors from SATOSA to the other service.
Right now I am just redirecting the browser to the error service with a
query string that includes the SP and IdP entityIDs so we can track
which SPs users were trying to access and which IdPs did not give us
anything we can use as an identifier.
I am not particularly happy with that either but I need something right
now and hope that some type of "standard" could evolve.
I am wondering if any other project might have use for
the microservice?
Any other thoughts?
I do not really have a use case in my mind, but the way I see what
you're trying to do is, as a fallback mechanism for an attribute to
get a value. Attribute
mapping does that but with less flexibility (ie
no special conditions with name_id, no error handling etc). I was
thinking if this can be implemented using the AttributeProcessor
service that was merged lately (but I need to understand the
requirements first).
Thanks. I will look at that in more detail.
2850
days inactive
2853
days old
6 comments
4 participants
participants (4)
-
ikakavas＠noc.grnet.gr -
ivan＠grnet.gr -
leifj＠sunet.se -
skoranda＠gmail.com