Authentication using federated identity

[Gilbert Netzer]

On 2024-02-12 22:15, Chris Rapier wrote:
> 
> 
> On 2/9/24 2:49 AM, Nico Kadel-Garcia wrote:
>> On Thu, Feb 8, 2024 at 1:18 PM Chris Rapier <rapier at psc.edu> wrote:
>>>
>>> I know that there are some methods to use federated identities (e.g.
>>> OAuth2) with SSH authentication but, from what I've seen, they largely
>>> seem clunky and require users to interact with web browsers to get one
>>> time tokens. Which is sort of acceptable for occasional logins but
>>> doesn't work with automated/scripted actions.
>>
>> Is there some reason you wouldn't simply use Kerberos, baked into
>> Samba and Active Directory, with the long established token handling
>> provided by Kerberos? Convincing Kerbers and the AD admin who may not
> 
> Largely because I'm trying to work within an existing system that has established methodologies. The really fun part is that I'd be trying to do this in a way that supports European R&E communities and US R&E communities which use different methodologies and have different organizational structures.
> 
> Prior experience with kerberos in these communities has not proven to be fruitful. It may be worth trying to revisit that, but I don't have any pull in transnational EU R&E HPN consortiums. They're pretty taken with OAuth which is great if you are doing everything in a browser. The US consortium I have more connections with but again, they're pretty taken with web based SSOs on their science gateways.
> 
> Chris
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

Hi Chris and others,

being on the European side of the coin in quite a similar situation was
actually the reason to subscribe to this list in the first place.

I can only support your analysis that if you want to hook into
existing federations your probably have to use some sort of web-technology.
In our case this is also done so that users, who typically have to authenticate
to their "home" institutions, can validate the authenticity of the login
page, for instance by checking the browsers SSL data.

Another important requirement for us is that the users, i.e. the client side,
do no have to install any "non-standard" software, but can essentially run with
"OS-provided" ssh-clients and web-browsers.  This since our users typically connect
to many HPC centers and have gotten pretty tired of doing something special for
each one of them.

In the end the not so elegant solution that we came up with is to use a
web-based service for users to upload their SSH public keys to us after
identifying themselves using the federated login.  While the users also have
to maintain a list of by them approved origins for login, for us IP-address
or DNS name patterns, they don't have to punch in one-time codes for every
login, at the expense of some security.

Technically for us the biggest challenge was that web-browsers, for good reason,
try to isolate a web-site from direct interaction with for instance
the file-system of the client-computer.  Consequently, we have not yet
found a good way to for example get a token, e.g. a SSH key or certificate,
in or out of the web-browser into the non-web part, for instance a SSH agent
or nice place of the file-system.  In the end our service basically asks
the user to locate the SSH pubic key file in the web-browsers file-chooser
dialog since one could not even make a suggestion of a file-name to
the web-browser that the user simply could approve.

It would be interesting to hear what your thoughts and progress is on that
matter since I am kind of looking to get to a more widely-used solution
than our current deployment.  On a side-node the Puhuri project
(https://puhuri.neic.no/) also provides some infrastructure
to handle SSH public keys for the LUMI supercomputer in Finnland.

Best Regards
Gilbert Netzer
PDC/KTH