new auth functions in trunk (basic, email/gmail, ldap)

[mdipierro]

Please try this....

1) to authenticate with gmail

auth=Auth(globals(),db)
from gluon.contrib.login_methods.email_auth import email_auth
auth.settings.login_methods.append(email_auth())

2) to authenticate using basic authentication of a third party server

auth=Auth(globals(),db)
from gluon.contrib.login_methods.basic_auth import basic_auth
auth.settings.login_methods.append(basic_auth('http://server'))

3) to authenticate using LDAP server

auth=Auth(globals(),db)
from gluon.contrib.login_methods.ldap_auth import ldap_auth
auth.settings.login_methods.append(ldap_auth(...))

(requires ldap library installed. look into gluon/contrib/
login_methods/ldap_auth.py for ... options).

Please let me know if this works for you.

CAS client will be next....

[Richard]

hi,

I tried testing the gmail authentication but I still get the standard
login form. Do I need to add something in the controller/view?

Have you seen the login form for stackoverflow.com? It lets you choose
between many providers, including gmail. Is something like that
possible through ldap_auth?

Richard

On May 13, 3:01 pm, mdipierro <mdipie...@cs.depaul.edu> wrote:
> Please try this....
>
> 1) to authenticate withgmail
>
> auth=Auth(globals(),db)
> from gluon.contrib.login_methods.email_auth import email_auth
> auth.settings.login_methods.append(email_auth())
>

> 2) to authenticate using basicauthenticationof a third party server

[mdipierro]

Hi Richard,

the gmail authentication is not based on open-id (yet). it presents
you with a standard login form. It tried to log you in via the normal
auth_user table. It it fails, it tried to verify your password using
the gmail smtp service. If that works a the auth_user table is created/
updated with the md5 hash of your current password.

This is designed to be streightforward to setup.

We will soon have an API like stack overflow does.

Massimo

[Alexei Vinidiktov]

On Mon, Jun 8, 2009 at 11:29 AM, mdipierro<mdip...@cs.depaul.edu> wrote:
>
> Hi Richard,
>
> the gmail authentication is not based on open-id (yet). it presents
> you with a standard login form. It tried to log you in via the normal
> auth_user table. It it fails, it tried to verify your password using
> the gmail smtp service. If that works a the auth_user table is created/
> updated with the md5 hash of your current password.
>
> This is designed to be streightforward to setup.

I see one drawback to this approach. If the user is logged in with
gmail credentials without leaving your site, he/she may be reluctant
to give them because he/she might be thinking "what if this site is
phishing for my credentials to gmail?"

What do you think?

>
> We will soon have an API like stack overflow does.
>

That's great to hear!

--
Alexei Vinidiktov

[notabene]

On Jun 8, 5:29 am, mdipierro <mdipie...@cs.depaul.edu> wrote:
> Hi Richard,
>
> the gmail authentication is not based on open-id (yet). it presents
> you with a standard login form. It tried to log you in via the normal
> auth_user table. It it fails, it tried to verify your password using
> the gmail smtp service. If that works a the auth_user table is created/
> updated with the md5 hash of your current password.
>
> This is designed to be streightforward to setup.
>
> We will soon have an API like stack overflow does.

? What do you mean: "an API like stack overflow" ??

[Richard]

On Jun 8, 1:29 pm, mdipierro <mdipie...@cs.depaul.edu> wrote:
> Hi Richard,
>

> thegmailauthentication is not based on open-id (yet). it presents

> you with a standard login form. It tried to log you in via the normal
> auth_user table. It it fails, it tried to verify your password using

> thegmailsmtp service. If that works a the auth_user table is created/

> updated with the md5 hash of your current password.
>
> This is designed to be streightforward to setup.

That's neat and easy to setup, but I agree with Alexei that the user
may be suspicious. I would need to highly trust the competence and
integrity of a third party before entering in my email login details.
How does it handle if I change my email login password so the hash is
out of date?

> We will soon have an API like stack overflow does.

That would be great. Will it redirect to each respective site to
login?

>
> Massimo
>
> On Jun 7, 10:22 pm, Richard <richar...@gmail.com> wrote:
>
> > hi,
>

> > I tried testing thegmailauthentication but I still get the standard

> > login form. Do I need to add something in the controller/view?
>
> > Have you seen the login form for stackoverflow.com? It lets you choose

> > between many providers, includinggmail. Is something like that

[mdipierro]

On Jun 8, 7:23 pm, Richard <richar...@gmail.com> wrote:
> On Jun 8, 1:29 pm, mdipierro <mdipie...@cs.depaul.edu> wrote:
>
> > Hi Richard,
>
> > thegmailauthentication is not based on open-id (yet). it presents
> > you with a standard login form. It tried to log you in via the normal
> > auth_user table. It it fails, it tried to verify your password using
> > thegmailsmtp service. If that works a the auth_user table is created/
> > updated with the md5 hash of your current password.
>
> > This is designed to be streightforward to setup.
>
> That's neat and easy to setup, but I agree with Alexei that the user
> may be suspicious. I would need to highly trust the competence and
> integrity of a third party before entering in my email login details.
> How does it handle if I change my email login password so the hash is
> out of date?

The user will be able to login with both password (the one stored
locally or the one stored remotely). If the user uses this remote
password, it is copied (hashed) locally.

This is not really the best/safest way to do it but it is not really
designed for a web2.0 app. This is designed for allowing a small group
of users trusting you already (employees of your company, clients,
etc.) to login without registering if they have already an account in
one of the trusted parties. Imagine for example you want to give login
access to people who already have an email (smtp) account on your
system.

> > We will soon have an API like stack overflow does.
>
> That would be great. Will it redirect to each respective site to
> login?

Yes. CAS does that. we need to ingrate everything in one app
customizable Auth.

Massimo

[mr.freeze]

Massimo, I can test ldap against AD when it is finished.

[mdipierro]

ldap should work already. Please test it.

[mr.freeze]

Sorry, I saw 'raise SyntaxError, "Not yet implemented"' under the 'ad'
and 'domino' if statements of ldap_auth_aux in ldap_auth.py and
thought you weren't done. I tried it and it seems that if ad/ldap is
enabled that it will take any username with a blank password.

[mdipierro]

only mode='uid' is implemented. I could use help debugging/
implementing the other modes

Massimo

[Trollkarlen]

Alexei Vinidiktov wrote:
> On Mon, Jun 8, 2009 at 11:29 AM, mdipierro<mdip...@cs.depaul.edu> wrote:
> >
> > Hi Richard,
> >
> > the gmail authentication is not based on open-id (yet). it presents
> > you with a standard login form. It tried to log you in via the normal
> > auth_user table. It it fails, it tried to verify your password using
> > the gmail smtp service. If that works a the auth_user table is created/
> > updated with the md5 hash of your current password.
> >
> > This is designed to be streightforward to setup.
>
> I see one drawback to this approach. If the user is logged in with
> gmail credentials without leaving your site, he/she may be reluctant
> to give them because he/she might be thinking "what if this site is
> phishing for my credentials to gmail?"
>
> What do you think?
>

Not only that its against the IT security rule no 1 to not have the
same passwords on different sites.
And in this case the chain is not stronger than the weakest link.

So it think this a potential security risk even thou its very handy.

/R

[mr.freeze]

I will take a stab at the active directory implementation ASAP.

[mr.freeze]

Massimo, you should have a patch in email for active directory ldap
auth. As noted in my email:
It works but we will also need to change tools.py so that it forces
ldap authentication each time, not just the first (maybe track the
auth method in the db?).
Currently after the account is authenticated through ldap, the
credentials are stored in the db and ldap is never queried again.

Also, ideally the login form would be specific to the the auth type so
ldap/active directory could include a domain name field.
Then we can tackle an LDAP membership provider!

On Jun 8, 11:52 pm, mdipierro <mdipie...@cs.depaul.edu> wrote:

> only mode='uid' is implemented. I could use help debugging/
> implementing the other modes
>
> Massimo
>
> On Jun 8, 10:38 pm, "mr.freeze" <nfre...@gmail.com> wrote:
>
>
>
> > Sorry, I saw 'raise SyntaxError, "Not yet implemented"' under the 'ad'
> > and 'domino' if statements of ldap_auth_aux in ldap_auth.py and
> > thought you weren't done.   I tried it and it seems that if ad/ldapis
> > enabled that it will take any username with a blank password.
>
> > On Jun 8, 10:04 pm, mdipierro <mdipie...@cs.depaul.edu> wrote:
>

> > >ldapshould work already. Please test it.

>
> > > On Jun 8, 9:29 pm, "mr.freeze" <nfre...@gmail.com> wrote:
>

> > > > Massimo, I can testldapagainst AD when it is finished.

>
> > > > On May 13, 12:01 am, mdipierro <mdipie...@cs.depaul.edu> wrote:
>
> > > > > Please try this....
>
> > > > > 1) to authenticate with gmail
>
> > > > >auth=Auth(globals(),db)
> > > > > from gluon.contrib.login_methods.email_auth import email_auth
> > > > >auth.settings.login_methods.append(email_auth())
>
> > > > > 2) to authenticate using basic authentication of a third party server
>
> > > > >auth=Auth(globals(),db)
> > > > > from gluon.contrib.login_methods.basic_auth import basic_auth
> > > > >auth.settings.login_methods.append(basic_auth('http://server'))
>

> > > > > 3) to authenticate usingLDAP server

>
> > > > >auth=Auth(globals(),db)
> > > > > from gluon.contrib.login_methods.ldap_auth import ldap_auth
> > > > >auth.settings.login_methods.append(ldap_auth(...))
>

> > > > > (requiresldaplibrary installed. look into gluon/contrib/

> > > > > login_methods/ldap_auth.py for ... options).
>
> > > > > Please let me know if this works for you.
>

> > > > > CAS client will be next....- Hide quoted text -
>
> - Show quoted text -

[mdipierro]

Thanks!

[mr.freeze]

I just sent you another (very simple) patch that forces auth to use
the alternative login methods if present so, for example, LDAP will be
queried each time.

On Jun 9, 11:30 pm, mdipierro <mdipie...@cs.depaul.edu> wrote:
> Thanks!
>
> On Jun 9, 11:03 pm, "mr.freeze" <nfre...@gmail.com> wrote:
>
>
>
> > Massimo, you should have a patch in email for active directory ldap
> >auth.  As noted in my email:
> > It works but we will also need to change tools.py so that it forces
> > ldap authentication each time, not just the first (maybe track the

> >authmethod in the db?).

> > Currently after the account is authenticated through ldap, the
> > credentials are stored in the db and ldap is never queried again.
>

> > Also, ideally the login form would be specific to the theauthtype so

> > > - Show quoted text -- Hide quoted text -

[mdipierro]

I did not receive your patch but if you now do:

auth.settings.login.methods=[ldap_login(..)]

then it does not store password in db and always requres ldap auth.
If you do:

auth.settings.login.methods=[ldap_login(..), auth]

same as above but does store password in db.
if you do

auth.settings.login.methods=[auth, ldap_login(..)]

tries to login locally first, else tries ldap.
Of course you can do

auth.settings.login.methods=[auth, ldap_login(...), email_login
(...), basic_login(...)]

and combinations thereof.

Please give this a try.

Massimo

[mr.freeze]

Almost perfect. Line 705 in tools.py should be:
if not self in self.settings.login_methods:
instead of
if not self in login_methods:

All of the combinations work as advertised with the change above.
Thanks!!! I will have a much easier time pushing web2py at work if we
can use our existing AD users.
Can you do the same thing to memberships now? :)

On Jun 11, 12:16 am, mdipierro <mdipie...@cs.depaul.edu> wrote:
> I did not receive your patch but if you now do:
>
>  auth.settings.login.methods=[ldap_login(..)]
>
> then it does not store password in db and always requres ldapauth.
> If you do:
>
>  auth.settings.login.methods=[ldap_login(..),auth]
>
> same as above but does store password in db.
> if you do
>
>  auth.settings.login.methods=[auth, ldap_login(..)]
>
> tries to login locally first, else tries ldap.
> Of course you can do
>
>  auth.settings.login.methods=[auth, ldap_login(...), email_login
> (...), basic_login(...)]
>
> and combinations thereof.
>
> Please give this a try.
>
> Massimo
>
> On Jun 10, 11:06 pm, "mr.freeze" <nfre...@gmail.com> wrote:
>
>
>

> > I just sent you another (very simple) patch that forcesauthto use

[mdipierro]

fixing!

On Jun 11, 6:58 am, "mr.freeze" <nfre...@gmail.com> wrote:
> Almost perfect.  Line 705 in tools.py should be:
> if not self in self.settings.login_methods:
> instead of
> if not self in login_methods:
>
> All of the combinations work as advertised with the change above.
> Thanks!!!  I will have a much easier time pushing web2py at work if we
> can use our existing AD users.
> Can you do the same thing to memberships now? :)

what do you mean?

[mr.freeze]

LDAP could be used to verify group membership too. It would be cool
if we could do something similar to login_methods:
auth.settings.membership_providers = [ldap_membership(...), auth]

Not sure how tricky the implementation would be though...

[mdipierro]

Not sure the web2py groups should be the same as the ldap groups.