[security-dev] Credentials API redesign

[Bill Burke]

On 12/6/2012 10:52 AM, Darran Lofthouse wrote:
> 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.
>

I agree.  I don't like the idea of the IDM API doing validation.  it 
should just be a federatable storage mechanism.

> 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.
>

If you look my proposal in one of my previous emails, the IDM is not 
performing validation and is only storing CredentialTypes as opaque 
objects.  The credential types know how to create handlers that can 
validate credentials.  Granted, this proposal currently requires java 
serialization, but there's no reason you couldn't normalize it into a 
set of credential-attribute tables like you do for user-attributes.

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