[Freeipa-users] External Collaboration Domains

[Simo Sorce]

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