Wondering if SASL is the perfect candidate for a challenge/response enabled authentication framework with multiple authentication mechanism support.
Wikipedia entry on SASL.
Apart from a challenge/response framework, it has support for the following protocols.
A SASL mechanism implements a series of challenges and responses. Defined SASL mechanisms[1] include:
- "EXTERNAL", where authentication is implicit in the context (e.g., for protocols already using IPsec or TLS)
- "ANONYMOUS", for unauthenticated guest access
- "PLAIN", a simple cleartext password mechanism. PLAIN obsoleted the LOGIN mechanism.
- "OTP", a one-time password mechanism. OTP obsoleted the SKEY Mechanism.
- "SKEY", an S/KEY mechanism.
- "CRAM-MD5", a simple challenge-response scheme based on HMAC-MD5.
- "DIGEST-MD5", HTTP Digest compatible challenge-response scheme based upon MD5. DIGEST-MD5 offers a data security layer.
- "SCRAM", modern challenge-response scheme based mechanism with channel binding support
- "NTLM", an NT LAN Manager authentication mechanism
- "GSSAPI", for Kerberos V5 authentication via the GSSAPI. GSSAPI offers a data-security layer.
- GateKeeper (& GateKeeperPassport), a challenge-response mechanism developed by Microsoft for MSN Chat
The GS2 family of mechanisms supports arbitrary GSS-API mechanisms in SASL.[2] It is now standardized as RFC 5801.
I consulted Darran about this and here are his thoughts.
(09:09:34 AM) anilsaldhana: darran: regarding a challenge/response based authentication framework, do u think sasl is sufficient?
(09:10:34 AM) anilsaldhana: darran: given that it has many possible protocols including silent
(09:11:50 AM) darran: asaldhan, from a non-HTTP perspective my feeling is yes, some of the Java provided APIs are not as easy / safe as they should be but the actual process at the transport level is good, we could optimise to do more concurrently but thats about it really
darran dehort
(09:13:07 AM) anilsaldhana: darran: right. I was asking mainly from non-http perspective.
(09:13:19 AM) anilsaldhana: darran: thanks for the guidance.
(09:13:53 AM) darran: a couple of API examples are CallbackHandler issues related to not clearly advertising what is supported or what is needed regarding callbacks, from a mechanism perspective there is also a lack of 'lifecycle' say to confirm success or failure of an auth process but all of these could be addressed without afecting the underlynig use of SASL
(09:14:42 AM) anilsaldhana: darran: of course.
PicketBox Core can natively support SASL. We will include darran's jboss-sasl project.