Jump to:

17452 Posts in 4473 Topics by 1971 members

Archive

SilverStripe Forums » Archive » External Authenticator

Our old forums are still available as a read-only archive.

Moderators: martimiz, Sean, biapar, Willr, Ingo, simon_w

Page: 1 2 3 4 5 6 7
Go to End
Author Topic: 62873 Views
  • lancer
    Avatar
    57 Posts

    External Authenticator Link to this post

    From the module README:
    ----------------------------------
    This module enables you to use external authentication sources for password
    verification. At the moment this module has 2 drivers. One for LDAP and
    one for IMAP which also supports POP3. TLS/SSL are supported for both drivers.

    When you use this module you will still need to create accounts within
    SilverStripe. There will be an extra field for each account, specifying the
    username in the external authentication source.

    If you run your website at your ISP which also hosts your mailbox, you can use
    the ISP's IMAP/POP3 server to validate your logon. Other users at the ISP
    cannot login when you do that, because the accounts also need to be registered
    within SilverStripe.
    ---------------------------------

    This topic is continued from the "LDAP Support for SilverStripe" thread from 'Contributions'.

    This module was originally released as an LDAP authenticator and then renamed to Simple Authenticator when IMAP/POP3 capabilities were added. Since the name was confusing, it is now renamed to External Authenticator. Updates with respect to the previous version:
    - Renamed the module
    - Added internationalization
    - Code layout cleanup

    Get a working (as far as I know) pre-release from
    http://www.gloudemans.info/publish/externalauth-0.1pre3.tar.gz

  • Markus
    Avatar
    Google Summer of Code Hacker
    152 Posts

    Re: External Authenticator Link to this post

    Hi Lancer,

    I had a quick look at your code! Looks good... great work man! I found 2 small “bugs”:

    * In drivers/IMAP.php line 38 a “)” is missing
    * In _config.php you first add “ExternalAuthenticatedRole” to the Member object and then
    you register the ExternalAuthenticator. You don’t need to call DataObject::add_extension() there. It’s called automatically in ExternalAuthenticator::on_register().

    Now I understood why you had those naming “problems” but I think that’s actually a bigger problem. By swapping out the code in “drivers” you prevent a user from using for example IMAP and LDAP authentication at the same time. Not really a problem with those two authentication mechanisms but you maybe you want to have a “backup system” if the other one is offline!?

    I think it would be much better to create to different modules so that they could also be used concurrently. Maybe we should refactor the LoginForm and Authenticator class to prevent that we have a lot of code redundancies.

  • lancer
    Avatar
    57 Posts

    Re: External Authenticator Link to this post

    Thanks for the bug report. Missed that one in all the _t function calls. Updated source is available.

    As for being not able to do LDAP and IMAP. I wonder how many installations actually use more than one authentication source. I like the suggestion of stacking drivers for redundancy, that should not be difficult to add. However stacking modules for different authentication sources is not wise, but that's a documentation issue.

    All the code excluding the driver files could be added to the core code. Even OpenID could be implemented in a driver file, the Authenticator, AuthenticatedRole and LoginForm were largely copied from the OpenID code.

    [edit]
    I just added an FTP driver as well
    see: http://www.gloudemans.info/publish/externalauth-0.1pre4.tar.gz
    [/edit]

  • Markus
    Avatar
    Google Summer of Code Hacker
    152 Posts

    Re: External Authenticator Link to this post

    > I wonder how many installations actually use more than one authentication source.

    Well.. since it is a brand-new feature I think that most sites at the moment don't use it at all, but we shouldn't restrict it's future use.

    > I like the suggestion of stacking drivers for redundancy, that should not be difficult to
    > add. However stacking modules for different authentication sources is not, but that's a
    > documentation issue.

    I'm not sure if you understood me. What I wanted to say was that at the moment all authentication methods share a lot of code within their LoginForms and their Authenticator classes. Maybe we should refactor them so that different authentication methods don't need to copy that code. That's exactly the reason why you created drivers and used ExternalAuthenticator and ExternalLoginForm for both drivers.
    But stacking drivers is also a good idea

    > All the code excluding the driver files could be added to the core code. Even OpenID
    > could be implemented in a driver file, the Authenticator, AuthenticatedRole and LoginForm > were largely copied from the OpenID code.

    That was exactly what I meant! We should build an infrastructure were we can simple add a driver (one file!?) without creating a special LoginForm and Authenticator class.
    Of course OpenID plays a special role since it uses redirects to another server (not just entering some kind of username and password) and so we have to design the Authenticator class flexible enough (just think about CardSpace, Google Account Authentication, LID, ...)

  • lancer
    Avatar
    57 Posts

    Re: External Authenticator Link to this post

    Sounds like a plan

    I would also expand the driver mechanism to the user administration itself. e.g. LDAP or AD (SilverStripe could use the standard POSIX scheme) can handle the user accounts as well as the database can. You might even want to use another database away from the SilverStripe database.

    I haven't read enough of the SilverStripe code to see the implications, but the implications are not limited to the authentication mechanism.

  • Markus
    Avatar
    Google Summer of Code Hacker
    152 Posts

    Re: External Authenticator Link to this post

    > Sounds like a plan

    > I would also expand the driver mechanism to the user administration itself.
    > e.g. LDAP or AD (SilverStripe could use the standard POSIX scheme) can handle the user
    > accounts as well as the database can. You might even want to use another database
    > away from the SilverStripe database.

    While this would be a desirable feature for enterprise applications I think it's too much abstraction for a simple CMS. Also it would require a lot of work to implement such a feature.
    But you could of build a bridge or proxy to support that

  • Sam
    Avatar
    Administrator
    679 Posts

    Re: External Authenticator Link to this post

    Great work on developing this module, lancer.

    We would love to host your module in our subversion repository / site and we've been thinking about what that might mean. We've put together a document outlining our thoughts here: http://doc.silverstripe.com/doku.php?id=module-maintainers.

    Would you be interested in making your module one of the official SilverStripe modules, hosted by us, with you as the maintainer?

  • lancer
    Avatar
    57 Posts

    Re: External Authenticator Link to this post

    Sure. Though I probably will be working with Markus to eliminate it again for some future version after 2.2.

    62873 Views
Page: 1 2 3 4 5 6 7
Go to Top

Want to know more about the company that brought you SilverStripe? Then check out SilverStripe.com

Comments on this website? Please give feedback.