Re: [kitten] GSS-API / SAML as authentication mechanism

[Srinivas Cheruku <[e-mail]>]

Simon,

Thank you very much for your inputs.

Does this mean it should be ok to use SAML20EC where application design assumes per-connection SASL authentication?

Thanks,
Srini


On 12/04/23, 18:39, "Simon Josefsson" <[e-mail]> wrote:
Srinivas Cheruku <[e-mail]<mailto:[e-mail]>> writes:

> Hello All,
>
> As you know, companies slowly starting thinking on moving away from
> Kerberos Infrastructure (e.g. MS AD) and relying on MS Azure AD or any
> other IdP for their authentication needs. We came across some new
> companies where they do not have any Kerberos infrastructure like MS
> AD at all. And, there are still thick client applications using
> GSS-API/Kerberos for the authentication and so was thinking on support
> for GSS-API/SAML for these client applications.
>
> I found two references as below:
>
>   1.  SAML Enhanced Client SASL and GSS-API Mechanisms -
> https://datatracker.ietf.org/doc/draft-ietf-kitten-sasl-saml-ec/
>   2.  RFC 6595 – A Simple Authentication and Security Layer (SASL) and
> GSS-API Mechanism for the Security Assertion Markup Language (SAML) -
> https://www.rfc-editor.org/rfc/rfc6595
>
> Are there any known implementations of these?

Yes, GNU SASL supports RFC6595 SAML20:

https://www.gnu.org/software/gsasl/manual/html_node/SAML20.html

However the deployment experience with IMAP/SMTP/XMPP and some other
SASL-using protocols has not worked out well for SAML20: the practice of
opening multiple connections and performing SASL authentication on each
of them pretty much destroyed the functionality here, where most
application design assumes per-connection SASL authentication is
non-interactive after an initial user prompt for passwords etc.

We never brought it up to the GSS-API layer to test with SSH etc, since
it is lacking some security features that makes it a bit too fragile.
SAML20EC improved on those, but the application design issue is still a
concern.

/Simon