11:22 a.m.
* U W <poubelle1430531(a)hotmail.fr> [2023-01-31 08:46]:
Yes I'm in France but the company is based in
Luxembourg
It doesn't really matter, you could join any federation of your
choosing, possible based on their cost (some federations charge money
for membership, many don't), (extent of any) formal requirements to
join, language(s) spoken, level/quality of their support (which may be
hard for you to know/find out beforehand, of course), etc.
So you could join https://www.eduid.lu/ or FER/RENATER or essentially
any other one you feel comfortable with. See section "For Service
Providers" on https://edugain.org/participants/how-to-use-edugain/
About Keycloak :
- unfortunately I have no other choice for the moment : it is in place
- but if you have a better OpenSource tool to recommend, I can
check/test it + discuss with developers to see if we can replace
Keycloak if this tool is better for us 😉
Without knowing your exact requirements it's very unlikely anyone
would be able to offer a suggestion. If you need something "exactly
like Keycloak but not Keycloak" I don't know of anything. ;)
Just a question about https://seamlessaccess.org/ : is
it an
intermediary to add in the chain ?
Depening on what you put in the chain/graph and why. SeamlessAccess is
an IDP Discovery Service (DS) that can be used by SAML SPs. With SAML
2.0 (there is no other atm) WebSSO the flow in the web browser
goes like this: SP -> DS -> SP -> IDP -> SP. And with "embedded"
deployment options of the DS it may even only look like SP -> IDP.
1. Keycloak -> Satosa -> SeamlessAccess ->
Edugain ?
2. Keycloak -> SeamlessAccess -> Edugain ?
If anything it would need to be 1, because Keycloak itself is not able
to be used as a SAML SP connecting to many IDPs (as discussed).
The role of the DS is merely to help the SP translate a descripton of
an IDP/institution the subject may be familiar with (e.g. "University
of Vienna") into an entityID. (So that function could be provided by
the local application, the SAML SP itself or some external service
such as SeamlessAccess).
In the end the result is always a SAML 2.0 authentication request to
the SAML IDP selected by the subject, issued (and possibly
cryptographically signed) by the SAML SP -- same as if no DS was ever
involved.
You can have a look at https://sp.eduid.at/ which demonstrates 3
different IDP Discovery Services in one SAML SP. (A real service would
of course not use all of those at once.)
You can trace the HTTP Requests and Reponses in your browser when
interacting with those (possibly using SAMLTracer or anything else oyu
prefer), maybe this will help clear up a few things.
HTH,
-peter