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