8:43 a.m.
Hello everyone,
My company develops a web application that uses Keycloak to authenticate / manages
users.
We would like to accept authentication from Edugain but Edugain is not only one
federation: it is an interconnection of many federations.
Therefore, if I want to accept Edugain it means I have to import one by one each Edugain
Federation and our end users have to choose the right one in a list.
Example:
- if I have these Edugain federations:
- Federation A
- Federation B
- Federation C
- Federation D
- I have to import / create an identity provider for each one in Keycloak:
- Federation A
- Federation B
- Federation C
- Federation D
- the end user has to choose the Edugain Federation in which he/she has an account:
Federation C
This is not a good option in term or ergonomy because there are too many federations...
I discovered Satosa and maybe I'm wrong (as I was not able to implement it yet) but I
have the feeling it could help us 🙂
The scheme I try to obtain is: our internal application -> Keycloak -> Satosa ->
Edugain
The idea is this one:
- Keycloak should see only one Identity Provider 'Edugain': in reality it is
Satosa behind
- and Satosa discovers the Edugain federations
I'm not comfortable with these technologies / these protocols (Keycloak, Satosa, SP,
IDP, SAML, etc) and therefore I don't understand how to configure all components...
Is this someone did the same (Keycloak or Gluu + Satosa + Edugain) and could share with me
an example of configurations please?
At least the Satosa configuration files (frontend, backend, etc).
Thank you very much :)
Bertrand
3:37 p.m.
* U W <poubelle1430531(a)hotmail.fr> [2023-01-30 15:53]:
Therefore, if I want to accept Edugain it means I have
to import one
by one each Edugain Federation and our end users have to choose the
right one in a list.
No, not using the system as it was desiged to be used, and using
proper software:
1. The eduGAIN Metadata Distribution Service publishes a signed
EntitiesDescriptor (SAML 2.0 Metadata) containing the union of all
entities published to become of eduGAIN" by each eduGAIN participating
federation. (So the aggregation but is already done.)
But even that's only an implementation detail.
2. Much more important is the fact that no individual IDP or SP should
ever consume the eduGAIN MDS document/metadata directly:
Instead, each eduGAIN member federation (I could only guess from your
email address ending in .fr and from your first name that this would
be "Fédération Éducation-Recherche" provided by RENATER,
https://services.renater.fr/federation/en/index) publishes a signed
(by them) metadata document containing their local entities plus all
entities that "are in eduGAIN" (or some permutation of these sets).
I.e., you'll need to find a "home federation"
https://technical.edugain.org/status (I'm guessing FER by RENATER)
that would register your service (and publish *towards* all entities
"in eduGAIN) and that federation will also provide you with a metadata
feed to consume where you learn about all entities "in edugain".
I'd suggest to either contact the eduGAIN support team
(https://edugain.org/contact/) or, if have you already decided that
RENATER is the best option for you, to contact RENATER about
subscribing as a partner, as mentionedn in their documentation,
https://services.renater.fr/federation/en/index
(Also available in French, of course:
https://services.renater.fr/federation/index )
The idea is this one:
- Keycloak should see only one Identity Provider 'Edugain': in reality it is
Satosa behind
- and Satosa discovers the Edugain federations
Mostly (see above). Keycloak is fundamentally broken wrt scalable
identity federation and as you would need to spoon-feed it all IDPs in
eduGAIN somehow, given that currently there are 5239 IDPs "in
eduGAIN", cf. https://technical.edugain.org/
To make matters worse, Keycloak as a SAML SP would require a single
ACS URL (where an IDP posts the SAML Reponse to) per IDP it has
configured locally, meaning your SP would have to have 5000+ ACS URLs
(and keep those current as IDPs join and leave eduGAIN).
So if you limit yourself to Keycloak (for other reasons / use-cases)
you'd at least need some extra tooling to do that, even with a
federation providing you with a single metadata document for all
IDPs.
Satosa (a SAML proxy, like Keycloak itself) might be one such tool.
I'm not comfortable with these technologies /
these protocols
(Keycloak, Satosa, SP, IDP, SAML, etc) and therefore I don't
understand how to configure all components...
That's not a good basis for getting good results fast (also taking
into account that federated authentication is security software) but I
guess you have to start somewhere. ;)
HTH,
-peter
3:54 p.m.
* U W <poubelle1430531(a)hotmail.fr> [2023-01-30 15:53]:
Therefore, if I want to accept Edugain it means I have
to import one
by one each Edugain Federation and our end users have to choose the
right one in a list.
As to the UI/UX part of that statement: Your end users would not
generally chose "the right" federation from the list of currently 78
eduGAIN participating federations, they would have to pick their
institutional SAML IDP (from the list of currently 5239 SAML IDPs) --
no matter which federation that IDP may be a part of.
So your SAML SP and/or its SAML IDP Discovery Service will need to be
fit to deal with potentially thousands of IDPs, not merely with dozens
of eduGAIN-participating federations.
To get a nice UI/UX for that IDP selection process you could use
https://seamlessaccess.org/ though.
HTH,
-peter
7:46 a.m.
Good morning,
Thank you for all details : from a theoretical point of view, it is clearer 🙂
Yes I'm in France but the company is based in Luxembourg : I just used my personal
e-mail address to publish in this mailing list 🙂
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 😉
Just a question about https://seamlessaccess.org/ : is it an intermediary to add in the
chain ?
If yes, what is the right chain :
1. Keycloak -> Satosa -> SeamlessAccess -> Edugain ?
2. Keycloak -> SeamlessAccess -> Edugain ?
Thank you very much 🙂
Bertrand
________________________________
De : Peter Schober <peter.schober(a)univie.ac.at>
Envoyé : lundi 30 janvier 2023 16:54
À : satosa-users(a)lists.sunet.se <satosa-users(a)lists.sunet.se>
Objet : [satosa-users] Re: Help to implement Satosa + Keycloak + Edugain
* U W <poubelle1430531(a)hotmail.fr> [2023-01-30 15:53]:
Therefore, if I want to accept Edugain it means I have
to import one
by one each Edugain Federation and our end users have to choose the
right one in a list.
As to the UI/UX part of that statement: Your end users would not
generally chose "the right" federation from the list of currently 78
eduGAIN participating federations, they would have to pick their
institutional SAML IDP (from the list of currently 5239 SAML IDPs) --
no matter which federation that IDP may be a part of.
So your SAML SP and/or its SAML IDP Discovery Service will need to be
fit to deal with potentially thousands of IDPs, not merely with dozens
of eduGAIN-participating federations.
To get a nice UI/UX for that IDP selection process you could use
https://seamlessaccess.org/ though.
HTH,
-peter
_______________________________________________
satosa-users mailing list -- satosa-users(a)lists.sunet.se
To unsubscribe send an email to satosa-users-leave(a)lists.sunet.se
10: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
6:43 p.m.
On 1/24/23 09:43, U W wrote:
The idea is this one:
- Keycloak should see only one Identity Provider 'Edugain': in reality it is
Satosa behind
- and Satosa discovers the Edugain federations
I'm not comfortable with these technologies / these protocols (Keycloak, Satosa, SP,
IDP, SAML, etc) and therefore I don't understand how to configure all components...
Is this someone did the same (Keycloak or Gluu + Satosa + Edugain) and could share with
me an example of configurations please?
At least the Satosa configuration files (frontend, backend, etc).
We have a web application that uses an OIDC interface to Satosa to get
authentication information for users provided by federated SAML IdPs,
some of them from EduGain.
All in all our setup looks roughly like this:
+---------+ OIDC +--------+ SAML +---------+
| Web App |---------| Satosa |---------| IdPs |
+---------+ +--------+ +---------+
| MDQ
+--------+ HTTP +--------------------------+
| pyFF |---------|Federation Metadata Server|
+--------+ +--------------------------+
| MDQ
+-----------+
| thisss.js |
+-----------+
Satosa handles the translation between SAML and OIDC.
The web app just sees a single OIDC ID Provider and Satosa takes care of
the SAML federation.
For a federation of the size of EduGain we ended up using pyFF with MDQ
to supply metadata to Satosa because this seems to scale a lot better
than importing the metadata directly into Satosa.
This also allows us to include exactly those IdPs that we want as pyFF
can do very flexible filtering an rewriting.
To allow users to select their home institution in a comfortable way in
a list that encompasses all the IdPs we import from multiple sources, we
run thisss.js as WAYF server.
I think a setup similar to this one should also work for your usecase.
If you run exactly with the IdPs from EduGain, then you also don't need
to run your own WAYF server but can use a public one instead.
-Chris
7:55 a.m.
Hi Christian, Bertrand,
We do exactly the same at CERN (eduGAIN -> Satosa -> Keycloak) and it works well.
We are also pretty happy with Keycloak as an open source AAI (it works with our number of
clients - roughly 12,000 - and seems to have a good sustainability model). I know the EOSC
team were also enhancing Keycloak to support federations properly. We also considered Gluu
when we were deciding.
Do you have any examples of a public WAYF?
We were also planning to use Satosa as an outbound proxy to eduGAIN for CERN users
accessing eduGAIN SPs. When I tried this a few years ago there were blocking issues with
encryption to shibboleth SPs so we had to roll back. I don’t know whether this is
solved.
Cheers,
Hannah
On 30 Jan 2023, at 19:43, Christian Franke
<christian.franke(a)chronist.net> wrote:
On 1/24/23 09:43, U W wrote:
The idea is this one:
- Keycloak should see only one Identity Provider 'Edugain': in reality it is
Satosa behind
- and Satosa discovers the Edugain federations
I'm not comfortable with these technologies / these protocols (Keycloak, Satosa, SP,
IDP, SAML, etc) and therefore I don't understand how to configure all components...
Is this someone did the same (Keycloak or Gluu + Satosa + Edugain) and could share with
me an example of configurations please?
At least the Satosa configuration files (frontend, backend, etc).
We have a web application that uses an OIDC interface to Satosa to get authentication
information for users provided by federated SAML IdPs, some of them from EduGain.
All in all our setup looks roughly like this:
+---------+ OIDC +--------+ SAML +---------+
| Web App |---------| Satosa |---------| IdPs |
+---------+ +--------+ +---------+
| MDQ
+--------+ HTTP +--------------------------+
| pyFF |---------|Federation Metadata Server|
+--------+ +--------------------------+
| MDQ
+-----------+
| thisss.js |
+-----------+
Satosa handles the translation between SAML and OIDC.
The web app just sees a single OIDC ID Provider and Satosa takes care of the SAML
federation.
For a federation of the size of EduGain we ended up using pyFF with MDQ to supply
metadata to Satosa because this seems to scale a lot better than importing the metadata
directly into Satosa.
This also allows us to include exactly those IdPs that we want as pyFF can do very
flexible filtering an rewriting.
To allow users to select their home institution in a comfortable way in a list that
encompasses all the IdPs we import from multiple sources, we run thisss.js as WAYF
server.
I think a setup similar to this one should also work for your usecase. If you run exactly
with the IdPs from EduGain, then you also don't need to run your own WAYF server but
can use a public one instead.
-Chris
_______________________________________________
satosa-users mailing list -- satosa-users(a)lists.sunet.se
To unsubscribe send an email to satosa-users-leave(a)lists.sunet.se
9:59 a.m.
* Hannah Short <hannah.short(a)cern.ch> [2023-01-31 08:55]:
I know the EOSC team were also enhancing Keycloak to
support
federations properly.
"Were enhancing" as in "it's done and generally available"?
That would be good news, I suppose.
Do you have any examples of a public WAYF?
You mean other than https://seamlessaccess.org/ (which I already referenced)?
We were also planning to use Satosa as an outbound
proxy to eduGAIN
for CERN users accessing eduGAIN SPs. When I tried this a few years
ago there were blocking issues with encryption to shibboleth SPs so
we had to roll back. I don’t know whether this is solved.
Shib SPs couldn't interop with Satosa when it's acting as a SAML IDP?
Is there an issue about this anywhere with the details?
-peter
6:21 a.m.
Hi Peter,
Shib SPs couldn't interop with Satosa when it's acting as a SAML IDP?
Is there an issue about this anywhere with the details?
https://github.com/IdentityPython/SATOSA/issues/337
I believe it was this one. I spent some time talking with Ivan and Christos at a TechEx
(or TNC?) about it several years ago. Honestly I don’t get how anyone could be using
Satosa as an IdP, so perhaps I’m missing something vital.
It’s possible it was fixed in https://github.com/IdentityPython/pysaml2/issues/738 - when
I get some time I will test again with the latest version of Satosa.
Cheers,
Hannah
On 31 Jan 2023, at 10:59, Peter Schober <peter.schober(a)univie.ac.at> wrote:
* Hannah Short <hannah.short(a)cern.ch> [2023-01-31 08:55]:
I know the EOSC team were also enhancing Keycloak to support
federations properly.
"Were enhancing" as in "it's done and generally available"?
That would be good news, I suppose.
Do you have any examples of a public WAYF?
You mean other than https://seamlessaccess.org/ (which I already referenced)?
We were also planning to use Satosa as an outbound proxy to eduGAIN
for CERN users accessing eduGAIN SPs. When I tried this a few years
ago there were blocking issues with encryption to shibboleth SPs so
we had to roll back. I don’t know whether this is solved.
Shib SPs couldn't interop with Satosa when it's acting as a SAML IDP?
Is there an issue about this anywhere with the details?
-peter
_______________________________________________
satosa-users mailing list -- satosa-users(a)lists.sunet.se
To unsubscribe send an email to satosa-users-leave(a)lists.sunet.se
12:01 p.m.
* Hannah Short <hannah.short(a)cern.ch> [2023-02-02 07:21]:
https://github.com/IdentityPython/SATOSA/issues/337
I believe it was this one.
Thanks, Hannah, also for following up on Github.
I spent some time talking with Ivan and Christos at a
TechEx (or
TNC?) about it several years ago. Honestly I don’t get how anyone
could be using Satosa as an IdP, so perhaps I’m missing something
vital.
It’s possible it was fixed in
https://github.com/IdentityPython/pysaml2/issues/738 - when I get
some time I will test again with the latest version of Satosa.
There's also https://github.com/IdentityPython/pysaml2/pull/778 and
that should have been merged almost two years ago (thanks to Giuseppe
and Ivan). So hopefully things are not as bad these days.
Cheers,
-peter
5:06 p.m.
On 1/31/23 08:55, Hannah Short wrote:
Hi Christian, Bertrand,
We do exactly the same at CERN (eduGAIN -> Satosa -> Keycloak) and it works well.
We are also pretty happy with Keycloak as an open source AAI (it works with our number of
clients - roughly 12,000 - and seems to have a good sustainability model). I know the EOSC
team were also enhancing Keycloak to support federations properly. We also considered Gluu
when we were deciding.
Do you have any examples of a public WAYF?
I don't have a good everview of all the available services, but when we
started out, we used the service provided by DFN:
https://wayf.aai.dfn.de/DFN-AAI-eduGAIN/wayf/www/WAYF.php
This service includes all the IdPs from DFN and eduGAIN.
Basically the limitation of any of these services is that you don't have
any control over the set of IdPs that is available and the way they are
represented, this is also the reason why we migrated to hosting our own
WAYF.
-Chris
9:55 a.m.
* Christian Franke <christian.franke(a)chronist.net> [2023-01-30 23:38]:
All in all our setup looks roughly like this:
+---------+ OIDC +--------+ SAML +---------+
| Web App |---------| Satosa |---------| IdPs |
+---------+ +--------+ +---------+
| MDQ
+--------+ HTTP +--------------------------+
| pyFF |---------|Federation Metadata Server|
+--------+ +--------------------------+
| MDQ
+-----------+
| thisss.js |
+-----------+
While this is all great (and no offence intended) let me just say that
I think it is complete madness to expect people to maintain this kind
of software stack only to enable them to connect one service "to
eduGAIN", i.e., to offer services to the academic community.
Just to provide some contrast: Personally I have used the Shibboleth
SP together with Apache httpd for many years with great success,
protecting many different kinds of applications and using different
kind of "application servers"[1]). This makes the setup essentially
look like this:
+---------+ SAML +--------+
| Web App |---------| IdPs |
+---------+ +--------+
But of course this does not have a mini-application-IDM system or
multi-protocol proxy such as Keycloak or Satosa in the mix. I also
realise people/projects have different needs and preferences and
deployment preferences change over the years.
Best,
-peter
[1] PHP-FPM + mod_proxy_fgci for PHP apps, uWSGI + mod_proxy_uwsgi for
Python and Perl (and Ruby), Tomcat + mod_proxy_ajp for Java.
For Node.js, golang, etc. based web servers resorting to HTTP/WS
Reverse Proxying from Apache httpd still works fine but I prefer
tunnelling with more "protocol fidelity" over HTTP/WS Reverse
Proxying whenever possible.
471
days inactive
480
days old
11 comments
4 participants
participants (4)
-
Christian Franke -
Hannah Short -
Peter Schober -
U W