Re: [security-dev] Credentials API redesign

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.