[security-dev] Credentials API redesign

[Darran Lofthouse]

On 12/06/2012 03:46 PM, Bill Burke wrote:
>
>
> On 12/6/2012 10:40 AM, 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'll elaborate.  For example, lets say the token solely establishes
> identity and role mappings/permissions are stored in the IDM.  A
> specific integration LoginModule for the 3rd party should be written
> that interacts with the server.  The user identity should be transformed
> into a username/userid that can be used to lookup role mappings within
> the IDM.
>
> Understanding and verifying the token with a third-party is beyond the
> scope of the IDM API IMO.  The IDM API should focus on storing and
> federating securitiy metadata.  It should not be worried about security
> protocols.

 From my perspective either the IDM is purely a store or the IDM has 
flexible support for credential validation - having a hybrid where some 
credential validation is accepted but other validation is not doesn't 
make sense to me.

If the IDM was not validating the credentials I could see the need for 
an intermediate project sitting on top of the IDM to perform the 
variations of validation that I require.

>