On Mon, 2014-04-14 at 12:23 +0200, Petr Spacek wrote: > 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.
http://www.umich.edu/~x509/ I already have a plan to implement this in Ipsilon eventually :-) > Is seems that variant (B) should be really simple to code/script when we have > SAML/OpenID capable IdP. It can be done indeed. Simo. -- Simo Sorce * Red Hat, Inc * New York _______________________________________________ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
