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.