[security-dev] Credentials API redesign

[Bill Burke]

On 12/6/2012 10:47 AM, Darran Lofthouse wrote:
>
>
> On 12/06/2012 03:40 PM, Bill Burke wrote:
>>
>>
>> On 12/6/2012 10:37 AM, Anil Saldhana wrote:
>>> On 12/06/2012 09:00 AM, Darran Lofthouse wrote:
>>>> I can see that there are cases where we know the User so it is desirable
>>>> to supply it but there are still the cases where we don't know the user
>>>> until after the credential has been verified.
>>> This actually is valid when integrating with proprietary 3rd party
>>> security systems.
>>> Assume a proprietary token coming into the authentication system and
>>> the auth system needs to pass this to the 3rd party system for
>>> deciphering and authentication. Once the 3rd party system validates and
>>> releases the user details, the auth system can perform its security
>>> context initialization etc.  This has been seen in the domain of the App
>>> Server with 3rd party sec systems.
>>>
>>
>> This is protocol specific and should not be handled by the IDM API.
>
> I think it depends how far you go, validating any credential could be
> classed as protocol specific.
>


There's a tipping point IMO from having a generic API that supports 
*OUR* vision of security vs. a third-party's vision of security.  What 
I'm saying is, if you have a non-trivial set of metadata that is 
controlled by a third-party, you're better off writing custom code than 
wrestling with the IDM API.

THis is why, IMO, it is so important to focus on *RED HAT*'s vision for 
security when it comes to the IDM API.  The LoginModule-like-SPI is 
where most of the third-party integration should occur.

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com