[security-dev] Credentials API redesign
darran.lofthouse at jboss.com
Thu Dec 6 07:18:16 EST 2012
On 12/06/2012 11:51 AM, Shane Bryzak wrote:
> On 12/06/2012 09:20 PM, Marek Posolda wrote:
>> and returned LoginResult contains some additional info about state
>> (LOGIN_SUCCESS, LOGIN_FAILED, MORE_STEPS_REQUIRED) and possible wrapps
>> User if state is LOGIN_SUCCESS or wrapps other info if the state
>> result was MORE_STEPS_REQUIRED. Maybe LoginState and LoginResult could
>> be single interface... not sure.
> We can support this by including the additional state within the
> LoginCredentials instance, however this might not be immediately obvious
> to most developers. I'll see if we can improve this in some way.
I think we need to be careful how far we take this so we don't reach the
position we did with JAAS previously.
The authentication approaches that we support need to be consistent with
different authentication mechanisms - as an example we don't just need
to be able to work with HTTP Digest we need to be able to work with SASL
Digest. When it comes to Kerberos for HTTP this would most likely be
SPNEGO but for SASL we are wrapping GSSAPI. Maybe it is fine but just
need to be careful we don't focus on one transport.
For mechanisms that also offer advanced capabilities such as integrity
protection over the whole request or response where do we see the
responsibility for this - Digest and GSSAPI both offer this.
Having the validation of Digest or GSSAPI tokens within the IDM now
means that the whole message body for both requests and responses needs
to be passed through the IDM. In addition to this we no longer just
have a call just for authentication we need processing as the request
processing completed to create the final response.
More information about the security-dev