[security-dev] Credentials API redesign

[Darran Lofthouse]

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.

Regards,
Darran Lofthouse.