Hello
I am building out an integration with some file transfer services that leverage OIDC for authentication but we have a need to use ssh key authentication given this is primarily going to be unattended / scripted type integrations. I know I can do the key registration / access in IDM, but am looking at the best approach to do the key-pair validation in AM. Has anyone done this or have recommendations on the architecture?
My options so far in terms of planning are:1
- Custom scripted authentication module
- Custom node that can be triggered to do the ssh key authentication against the principal
Anyone have recommendations on getting this done?
Appreciate the help and any pointers on doing this.
Thanks
Nick
Hi Nick,
There is not enough information for me here.
Such as, I could interpret your comments as:
OIDC to access RS. RS accesses files with scp?? ssh key validation to the scp service??
Thus, You would like to include a claim for the ssh key in the OIDC token?
OR, is it necessary that in the authentication process of AM include the resolution of an ssh key prior to issuance of OIDC token? (Which is how I interpret your request)
I have not done ssh key validation in AM since the product “SUNWam”. As you know, the STS does not include a flow for ssh key validation and exchange. Moreover there is neither a module nor node which performs sshkey validation… therefore a custom node or script to validate the key.
Some would consider an approach of key validation without communications to sshd and strictly use validation against the “keystore”.
Care to elaborate? Looking forward to others’ input.
Cheers.
Yeah, so the use case here is going to be more client / gateway integration and authentication. In our API gateway and managed file transfer tooling, we have the capability to do username / password and OIDC flows. But, also have the capability to do key based flows. To provide consistency for users we are going to manage all the connections / policy / etc in FR.
So, to answer your questions, the /authenticate and/or token endpoints may still get a password field for a password or other flow, but it is going to be a key (tagged with key / info for routing) I just need to find a way to do the validation in the authentiction modules (since is not an ldap lookup, is a key validation method). From there, a pass/fail can be passed back to the calling gateway for the connection along with any policy / token info for the session that may be needed.
Nick
Got it. Yes, with X.509 certificates, we performed validation against the directory, as well.
But the ssh keys… should to be validated via the sshd service (And of course, LDAP acting as the data store to support sshd by storing the public keys can and has been done.)
There is no facility in AM to communicate to sshd and request validation of the private key, today, that I know of. Neither is there such a mechanism with the SASL layer in DS.
Nick, I enjoy these thought and architecture provoking conversations. Thanks for this.
Cheers.
Yeah, this one is a bit of a head scratcher. Challenge is there are multiple ways to handle ssh / key authentication depending on the implementation. Some may use signing of a nonce and validation based on the public key in the directory, some use key pair validation libraries.
So, based on this, since this is part of an existing stack that has an SSH implementation built in, am debating if I authorize the connection, pass back the stored key from the identity record, and let the gateway do their ‘key authentication’ validation. Or, try to write a custom node that does the same in AM so can do the authentication.
Nick
Well, if we consider that AM Auth-N processes “outsource” the means or validation of authentication to an “authoritative authentication source”, I’m in the camp that dictates its the sshd that is responsible for the validation.
Or, if we consider that the gateway performs its valid session management/Auth-Z with success in Auth-N, I would argue similarly as above… that sshd has a role here.
These are the great debates that boil down to a preference and an ease to implement.
Cheers