[OpenAM] Chained Authentication - single login form

Major Péter majorpetya at sch.bme.hu
Wed Dec 29 18:03:40 GMT 2010


Well this should work too.

Pros:
* easier to switch auth modules in the chain
* You don't have to follow up LDAP and RADIUS module changes in trunk

Cons:
* you have to develop two (small) auth modules
* your auth chain now contains 4 modules instead of 1

The decision is yours ;)

Regards,
Peter

2010-12-29 18:47 keltezéssel, Allan Foster írta:
> Ahhhh
>
> OK I see the issue here..... You WANT to actually prompt for both
> passwords, and not an either/or
>
> OK, Yes So to do this you will have to do some development.
>
> The easiest would be: to write 2 Auth Modules.
>
> 1) the first module would prompt for the 3 params, and save them into
> the sharedstate.
> 2) then put in the LDAP module...
> 3) a small auth module that simply copies pwd2 to pwd in sharedstate
> 4) Radius module.
>
> That way, module 1 will prompt for the params, and simply put them into
> sharedstate, and return 0 (Skip)
> Mod 2 does normal LDAP. (using params from shared state)
> Mod 3 put the Radius Key into the right sharedstate key (password) and
> returns 0 (Skip)
> Mod 4 is normal Radius (using input from sharedstate)
>
> How about THAT?
>
> Allan
>
> On 12/29/10 9:33, michaelg at virtuall.com wrote:
>> So when I said the values were not the same what I meant was that what the
>> user enters are two completely different values.  So in our chained
>> authentication if we have userA logging in they would enter:
>>
>> username:  userA
>> password:  userApassword  (this is the password assigned in the LDAP)
>> passcode:  123456  (this is a one time passcode generated by a harware
>> token that is in the user's possesion - it is different each time the user
>> logs in.  Similar to the HOTP, but using a harware token and linked to the
>> RADIUS server)
>>
>> But what I see in the example you give is using the same value passed
>> ("pwd") for each authentication:
>>
>>   save (password,"pwd");
>>   token = getFromShared("pwd");
>>
>> I need to have the value of "pwd" different for each chain.
>>
>>   save (password,"pwd");
>>   token = getFromShared("pwd2");
>>
>> But I still don't see how I can do that on a single form without creating
>> a custom authentication module that defines two seperate elements to hold
>> password and passcode values.
>>
>> of course it could just be that my head is too full of eggnog to make
>> sense of this.
>>
>>
>>
>>> Not quite Michael.
>>>
>>> it turns out the The Shared State uses the password key to store the
>>> value,  that is used by ldap and radius.
>>>
>>> So in fact the radius module will use the LDAP password value as its
>>> Token callback,  if you set those options.
>>>
>>> LDAP -->
>>> Save (name,"name");
>>> save (password,"pwd");
>>>
>>> Radius -->
>>> name = getFromShared("name");
>>> token = getFromShared("pwd");
>>>
>>> So in fact,  if you enter the Radius password or token into the password
>>> field,  radius will use that as the token, and ignore the callbacks.
>>>
>>> Allan
>>>
>>>
>>> On 12/28/10 13:31,michaelg at virtuall.com  wrote:
>>>> The problem I see with the proposed solution (unless I'm completely off
>>>> base on what you're saying, which is entirely possible) is that the
>>>> password value for the LDAP and the passcode value for the RADIUS are
>>>> two
>>>> completely different values.  So I need to capture both values for the
>>>> authentication module's callbacks.
>>>>
>>>>> Hi Michael
>>>>>
>>>>> So it turns out that both LDAP and Radius use the password as their
>>>>> key.
>>>>>
>>>>> So if you use
>>>>> Username:
>>>>> Password/Token:
>>>>>
>>>>> The Value of the apssword will be sued for password on LDAP and the
>>>>> TokenID for radius
>>>>>
>>>>> Woudl that work?
>>>>>
>>>>> Allan
>>>>>
>>>>> On 12/28/10 12:22,michaelg at virtuall.com  wrote:
>>>>>> Hi Allan,
>>>>>>
>>>>>> Thanks for the info.  One question though.  The LDAP authenticaiton
>>>>>> uses
>>>>>> a
>>>>>> password but the RADIUS uses a one-time passcode generated from a hard
>>>>>> token.  As I read what you sent it suggests that the two
>>>>>> authentication
>>>>>> modules utilize the same value for the password.  So what I need to
>>>>>> get
>>>>>> to
>>>>>> is a form that prompts for:
>>>>>>
>>>>>> user name:  (where username is both the LDAP and the RADIUS username)
>>>>>> Password:   (password for the LDAP entry)
>>>>>> Passcode:   (one time pass code for the RADIUS entry)
>>>>>>
>>>>>>
>>>>>> With that will what you suggest still work?
>>>>>>
>>>>>> thanks
>>>>>>
>>>>>>
>>>>>>> Hi Michael
>>>>>>>
>>>>>>> Yes, you can do this. When you set up the Options for the login
>>>>>>> modules,
>>>>>>> in the chain, the following two attributes control passing
>>>>>>> Credentials
>>>>>>> between modules:
>>>>>>>
>>>>>>> *iplanet-am-auth-shared-state-enabled* - This option enables the use
>>>>>>> of
>>>>>>> a shared state map.
>>>>>>> *iplanet-am-auth-store-shared-state-enabled* - This option enables
>>>>>>> the
>>>>>>> storage of credentials to a shared state map.
>>>>>>> *iplanet-am-auth-shared-state-behavior-pattern* - To prevent a user
>>>>>>> from
>>>>>>> having to enter the user identifier and password twice for
>>>>>>> authentication, set this option to useFirstPass for all modules in
>>>>>>> the
>>>>>>> chain (except the first). The default value tryFirstPass would prompt
>>>>>>> for new credentials if the shared state credentials fail.
>>>>>>>
>>>>>>> You will have to enableSharedState and then set the appropriate
>>>>>>> pattern
>>>>>>> for your subsequent modules
>>>>>>>
>>>>>>> Allan
>>>>>>>
>>>>>>> On 12/28/10 11:45,michaelg at virtuall.com  wrote:
>>>>>>>> We are using chained authentication utilizing the LDAP and RADIUS
>>>>>>>> modules
>>>>>>>> both requisite.  Works great but we need a single login form rather
>>>>>>>> than
>>>>>>>> the current two login forms.  Is there a simple configuration change
>>>>>>>> that
>>>>>>>> would handle this or do we need to create a custom authenticaion
>>>>>>>> module
>>>>>>>> that combines the two?
>>>>>>>>
>>>>>>>> thanks
>>>>>>>> mike



More information about the OpenAM mailing list