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