[Freeipa-users] External Collaboration Domains

[Petr Spacek]

On 13.4.2014 15:21, Dmitri Pal wrote:
>>> There is where I see a leap of faith. SAML -> SSH. It is not possible.
>>> And I am not sure OpenSSH would be interested to support it. They had
>>> hard time supporting Certs.
>> No SAML->SSH. Even if it were possible, it would involve configuring every
>> host in the domain individually. Ick.
>>
>> Browser->Gateway->TGT->Service TKT->SSH. Like normal.
>
> There is no way to deliver TGT to the client. Also there is no TGT on the
> server. TGT can be acquired only using the real credential by principal in the
> initial auth. But this means that principal has a local credential (password,
> cert, token...). But this means it is not an external account any more.
> Full stop. Sorry.
>
>> GSSAPI/OpenID->GSSAPI acceptor->TGT->Service TKT->SSH. Like normal. or
>
> Does not work. Not possible. You can't get TGT using any kind of service ticket.
>
>> GSSAPI/SAML->GSSAPI acceptor->TGT->Service TKT->SSH. Like normal.
>
> See above. This is the flaw in the whole idea.
>
>
> As I said there are two problems:
> a) You can't get TGT using a service ticket
> b) If you got a ticker on the server side there is no way to deliver this
> ticket out of band not over kerberos protocol and stick it into the client.

Please note that Ticket Granting service is extensible. Nowadays we have plain 
Kerberos and PKINIT built on top of it. PKINIT is different way how to get TGT 
(in comparison to plain Kerberos).

I think it would be possible to build some machinery around that.

Variant (A) - IdP + PKINIT:
A1) User authenticates to his SAML/OpenID provider (external domain)
A2) User locally generates CSR
A3) User contacts IdP (gssapi/saml ; gssapi/openid) and sends CSR to the IdP
A4) IdP returns short-lived certificate (validity period matches policy for TGT)
A5) User presents certificate issued by IdP to KDC
A6) KDC authenticates user via PKINIT and issues TGT as usual

This variant doesn't require any change to Kerberos protocol. It needs IdP 
with CA + some client software automating described steps.


Of course, it would be possible to add a new mechanism like PKINIT. Obvious 
disadvantage is that it require changes in Kerberos protocol - i.e. definition 
of the new mechanism and implementation to KDC and Kerberos libraries.


Variant (B) - IdP without PKINIT is almost the same, just uses symmetric crypto:
A1) User authenticates to his SAML/OpenID provider (external domain)
A2) User contacts IdP (gssapi/saml ; gssapi/openid) and sends authentication 
request
A4) IdP changes principal password to some random value and sends keytab back 
to the user (via GSSAPI-secured connection)
A5) User uses keytab to get TGT from KDC

Obvious problem is that keytab received by user has to be short-lived. For 
example, IdP could generate a new random password for user principal 1 minute 
after sending keytab to the user.

This could work if the whole process should be automated.


Is seems that variant (B) should be really simple to code/script when we have 
SAML/OpenID capable IdP.

> Knowing Kerberos community for 6 years I would say the chances for this to
> change are close to 0. I am not sure wheather it is even a good idea to change
> it. Also the change would require a change to all the browsers and this is a
> showstopper in itself.
>
> I think it would be easier to create an SSH client plugin that uses existing
> protocols and flows but it is again a huge task in itself.
IMHO GSSAPI is the right layer to focus on, not the SSH itself.

-- 
Petr^2 Spacek