Authentication Poll & Community Design [PLEASE JOIN!]

Not for 'how-to' coding questions but PHP theory instead, this forum is here for those of us who wish to learn about design aspects of programming with PHP.

Moderator: General Moderators

Your authentication is...

Homegrown
61
91%
PEAR
4
6%
Non-PEAR but third-party
0
No votes
Borrowed from other software coexisting with app
2
3%
 
Total votes: 67

santosj
Forum Contributor
Posts: 157
Joined: Sat Apr 29, 2006 7:06 pm

Post by santosj »

arborint wrote:I was just present that code as an example of the basic form controller logic. There is no authentication code shown and my comment was only that some of those calls would internally need to make use of our auth library. I think that is form code that just about any PHP programmer could follow -- and it does not dictate anything about the acutal presentation of the form. For example, the $form->render() method could use Smarty or TemplateLite or something else.
So, your code is dependent on the Auth class as oppose to my example which the Auth class accepts as a plugin. I like my example better since it would be more modular, but from a practical standpoint, your example would be easier.
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Post by Christopher »

santosj wrote:So, your code is dependent on the Auth class as oppose to my example which the Auth class accepts as a plugin. I like my example better since it would be more modular, but from a practical standpoint, your example would be easier.
Yes, I think that the Auth code should have no dependencies on any presentation code -- PEAR::Auth does it that way with callbacks. As I have said, I think the application should acquire the credentials (whether username/password or remember me cookie), provide the known datasource (to validate againse), and a persistence mechanism (for session data).

We can certainly supply some canned presentation code to make building simple login pages easier though.
(#10850)
User avatar
RobertGonzalez
Site Administrator
Posts: 14293
Joined: Tue Sep 09, 2003 6:04 pm
Location: Fremont, CA, USA

Post by RobertGonzalez »

Can we provide a single config file that can be read by the app? That way a user can specify some important information in a single place without having to do anything with the app. Things like telling the app if there is a user form to include (and if not, we can add in a canned one), if they will be using a database or files for user data, etc. That way we can effectively develop the app without the need for a user to do anything inside of it. What do you all think about this idea?
User avatar
Ambush Commander
DevNet Master
Posts: 3698
Joined: Mon Oct 25, 2004 9:29 pm
Location: New Jersey, US

Post by Ambush Commander »

I had, as Everah puts it, a slight epiphany while I was taking a walk. The relevation?

There is no way to definitely, 100% authenticate a person.

Which leads to the axiom,

There can be multiple factors used to determine whether or not a person is authenticated.

or

Authentication is not a binary attribute.

Still trying to digest the implications of this revelation.
Last edited by Ambush Commander on Sun May 21, 2006 7:53 pm, edited 1 time in total.
User avatar
RobertGonzalez
Site Administrator
Posts: 14293
Joined: Tue Sep 09, 2003 6:04 pm
Location: Fremont, CA, USA

Post by RobertGonzalez »

Ambush Commander wrote:I had, as Everah puts it, a slight epiphany while I was taking a walk. The revalation?

There is no way to definitely, 100% authenticate a person.

Which leads to the axiom,

There can be multiple factors used to determine whether or not a person is authenticated.

or

Authentication is not a binary attribute.

Still trying to digest the implications of this revelation.
I had thought of this at a point. My thought was that we can only truly authenticate a user against credentials the user supplied at some point (say during registration). Of course, that may or may not be good enough for a user's app, but the situation does exist that a user may lose, leak or disseminate their information into the publis realm at which point security of that information has been compromised before it ever gets to the app. The app could easily authenticate creditials, but is it really authenticating the user? Do we need to worry about this?

Questions, questions...
User avatar
Ambush Commander
DevNet Master
Posts: 3698
Joined: Mon Oct 25, 2004 9:29 pm
Location: New Jersey, US

Post by Ambush Commander »

My thought was that we can only truly authenticate a user against credentials the user supplied at some point (say during registration). Of course, that may or may not be good enough for a user's app, but the situation does exist that a user may lose, leak or disseminate their information into the publis realm at which point security of that information has been compromised before it ever gets to the app. The app could easily authenticate creditials, but is it really authenticating the user? Do we need to worry about this?
No, we don't. We're not here to create some revolutionary new 100% fraud-proof authentication method. What we do have to worry about is how the application will "weight" different types of credentials. For a simple use case, any credential will fit, but for more sensitive transactions, the authentication can't be based solely from a remember me (SourceForge does this).

::other replies still pending::
User avatar
Ambush Commander
DevNet Master
Posts: 3698
Joined: Mon Oct 25, 2004 9:29 pm
Location: New Jersey, US

Post by Ambush Commander »

Here's some replies I promised.
Can we provide a single config file that can be read by the app? No. But not for the reasons you put forth. That way a user can specify some important information in a single place without having to do anything with the app. Things like telling the app if there is a user form to include (and if not, we can add in a canned one), if they will be using a database or files for user data, etc. That way we can effectively develop the app without the need for a user to do anything inside of it. They shouldn't need to do any edits. But you don't need a configuration file. What do you all think about this idea?
My responses in bold. Here's my assertion: configuration files, in there essence, are global pieces of information. Globals are usually frowned upon, because it's difficult to track what's going on with them, but are quite useful when a particular parameter needs to be passed several levels deep and you don't want to bubble it through parameters.

There is no need, however, for the Authentication component to have to do this. Passing everything by parameter, at this point, is still quite feasible.

However, if people insist, we can add another function wrapper that can pass a configuration array. More features.

On the use-case creep - As we add even more and more ways to use the application, it will be difficult to instruct users how to use it at all (Oh, you can use this class in 100 ways). Perhaps we could classify them from most intrusive to least intrusive or something, or perhaps organize them "wizard"-style?
Yes, I think that the Auth code should have no dependencies on any presentation code -- PEAR::Auth does it that way with callbacks.
So you force it the other way: the auth code is not dependent on presentation, the presentation is dependant on Auth code! That is, the presentation has to know about how to get info from the auth code, even if it's through some mediating wrapper. We could bundle a Smarty extension with our app to facilitate login form generation.
As I have said, I think the application should acquire the credentials (whether username/password or remember me cookie), provide the known datasource (to validate againse), and a persistence mechanism (for session data).
Agreed, but the auth module also needs to be able to autodetect this stuff.
We can certainly supply some canned presentation code to make building simple login pages easier though.
Some of the most spectacular extra features (notably challenge/response and RSA encryption) will require a substantial bit of client-side work. Then the canned presentation code becomes a must. ;-)
Also, I'm trying to think of a good excuse to use SPL Observer
Try not to get too attached to SPL. Not everyone knows what they are. (I do know what they are but have never used them)

Santosj's code at this post - I finally think I understand it. And that wasn't an easy process. Reflection makes stuff so much harder to use.

Santosj, if we really needed the form to be that configurable, I'm sure the developer would have their own pet form generation system. Plus, I don't see why we couldn't just...

Code: Select all

$authform->paintStart('confirm.php');
$authform->paintUsername();
$authform->paintPassword();
$authform->paintEnd();
And I've done this before and it's a pain. Sorry, but no.

arborint's code from this post

My previous objection could be circumvented with santosj's suggestion that the raw post data just be serialized and then reinstantiated when the user travels back to the appropriate page. This is, however, out of our scope, because there are security/filesystem implications for things like uploads and passwords (which ideally aren't persisted in plaintext form).
The code is awesome. Do you have down what all of the classes are at this point?
No, but that use code shows us what the API looks like.

User/password as exceptions

I agree that they shouldn't be exceptions, but for different reasons. Any controller worth its salt should be able to intercept a not authorized/bad login credentials and redirect application flow to the appropriate page. Plus, the thin-ness of application should make it possible to bubble it all the way up without too much problem (the greatest feature of exceptions is the ability to bypass this bubbling).
I need a little time to think about the code you posted.
I'd like to hear a reply some time or another, because I'm going to be augmenting that code pretty soon.
Htaccess does everything in and of itself
Correct. We're not dealing with htaccess.
HTTP basic authentication.
That's another way to get credentials, and it's probably the way to manage authentication for a user who doesn't accept cookies.

Yes, all replies done!
User avatar
Ambush Commander
DevNet Master
Posts: 3698
Joined: Mon Oct 25, 2004 9:29 pm
Location: New Jersey, US

Post by Ambush Commander »

Oh, by the way, we're using SimpleTest, right?

Another random point http://www.xml.com/pub/a/2003/12/17/dive.html is another interesting way to handle the no-SSL problem.

Java, of course, has their own authentication/authorization framework. JAAS. Read more: http://java.sun.com/j2se/1.4.2/docs/gui ... nOnly.html http://java.sun.com/j2se/1.4.2/docs/gui ... e.html#Who

Another feature! - Single Signon!
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Post by Christopher »

Ambush Commander wrote:So you force it the other way: the auth code is not dependent on presentation, the presentation is dependant on Auth code! That is, the presentation has to know about how to get info from the auth code, even if it's through some mediating wrapper. We could bundle a Smarty extension with our app to facilitate login form generation.
I really can't keep up with all this info so I will only respond to direct suff. I think there is a huge difference between the the two dependencies -- if the auth code is dependent on the presentation we have no way of guaranteeing that it works. If the presentation (i.e. the app) is dependent on the auth code then we can create modular, testable units.
Ambush Commander wrote:
As I have said, I think the application should acquire the credentials (whether username/password or remember me cookie), provide the known datasource (to validate againse), and a persistence mechanism (for session data).
Agreed, but the auth module also needs to be able to autodetect this stuff.
We can certainly supply some canned presentation code to make building simple login pages easier though.
Some of the most spectacular extra features (notably challenge/response and RSA encryption) will require a substantial bit of client-side work. Then the canned presentation code becomes a must. ;-)
I'm not sure what you mean by "autodetect"? Please explain. If you mean that if a plugin feature is installed (e.g. remember me) then the system uses it -- then we are in agreement.
(#10850)
User avatar
Ambush Commander
DevNet Master
Posts: 3698
Joined: Mon Oct 25, 2004 9:29 pm
Location: New Jersey, US

Post by Ambush Commander »

I really can't keep up with all this info so I will only respond to direct suff.
Hahaha... at some point I'll have a nervous breakdown and then we'll have eight+ pages worth of discussion that no one will be able to understand. I'd still like to request (if you didn't see my other request) that you comment some time or another on the authtools_quick_authenticate() function.
I think there is a huge difference between the the two dependencies -- if the auth code is dependent on the presentation we have no way of guaranteeing that it works. If the presentation (i.e. the app) is dependent on the auth code then we can create modular, testable units.
I didn't say I was against it. :)
I'm not sure what you mean by "autodetect"?
It means different things for each type, but in general, it's the automatic instantiation of packaged wrappers for the most common solutions out there. For datasource, it counts as a MySQL DB class that uses the default table and column names and depends on mysql_*'s cached resource. For persistence mechanism/session data it depends on the default session cookie name and a custom entry for itself in the $_SESSION array. For request, I already demonstrated AuthTools_Credentials_Auto. That's autodetection.

Even remember me could be auto-detected, even though we have agreed that it is a plugin. Maybe we should also have an AuthTools_Controller_Full which loads all plugins... Hmmm... Plugins cause interesting packaging problems. What about installing new packages? I'd rather have all the code just sitting around, ready to be used, but not parsed/included.
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Post by Christopher »

Ambush Commander wrote:I'd still like to request (if you didn't see my other request) that you comment some time or another on the authtools_quick_authenticate() function.
I think it might be a good idea at this point to focus on one thing at at time after the last five page ideafest! That sound like a good place to start. Can you repost it
Ambush Commander wrote:
I'm not sure what you mean by "autodetect"?
It means different things for each type, but in general, it's the automatic instantiation of packaged wrappers for the most common solutions out there. For datasource, it counts as a MySQL DB class that uses the default table and column names and depends on mysql_*'s cached resource. For persistence mechanism/session data it depends on the default session cookie name and a custom entry for itself in the $_SESSION array. For request, I already demonstrated AuthTools_Credentials_Auto. That's autodetection.

Even remember me could be auto-detected, even though we have agreed that it is a plugin. Maybe we should also have an AuthTools_Controller_Full which loads all plugins... Hmmm... Plugins cause interesting packaging problems. What about installing new packages? I'd rather have all the code just sitting around, ready to be used, but not parsed/included.
I think I would prefer an explicit system that only did what I told it to, but I don't think your auto-detect and my manual stuff are exclusive. I think the core should be manual and automatic wrappers can be placed around it with reasonable defaults and conventions -- I think that makes a lot of sense. I guess I am more focused on the simplest core right now.
(#10850)
User avatar
Ambush Commander
DevNet Master
Posts: 3698
Joined: Mon Oct 25, 2004 9:29 pm
Location: New Jersey, US

Post by Ambush Commander »

I think I would prefer an explicit system that only did what I told it to, but I don't think your auto-detect and my manual stuff are exclusive. I think the core should be manual and automatic wrappers can be placed around it with reasonable defaults and conventions -- I think that makes a lot of sense. I guess I am more focused on the simplest core right now.
Exactly! :D
I think it might be a good idea at this point to focus on one thing at at time after the last five page ideafest! That sound like a good place to start.
So... let's focus on authtools_quick_authorize()! (reposted here as a reminder) (your comment really didn't jive with the quote, so I'm assuming that you endorse this?)

Code: Select all

// if user authenticates, use user is authorized
function authtools_quick_authorize($continue_execution = false)
{
    $credentials = new AuthTools_Credentials_Auto();
    $controller = new AuthTools_Controller();
    $command_chain = $controller->getCommandChain($credentials);
    // Command chain works this way:
    //     Depending on the credentials, multiple actions could be going on.
    // if a user has a session and a remember me token, both commands get
    // added to the chain. The application first tries to resume the
    // session: if that fails, it then tries to create a new session from
    // the remember me token. Otherwise, a failed session could preclude a
    // user from redeeming their remember me token.
    $command_chain->executeCommands();
    $auth_status = $command_chain->getAuthenticationStatus();
    $is_authenticated = $auth_status->isAuthenticated();
    $is_authorized = $is_authenticated; // is_authenticated is equivalent to is_authorized
    if ($continue_execution) {
        return $is_authorized;
    }
    if (!$is_authorized) {
        $form = new AuthTools_BasicForm($auth_status);
        echo $form->getContents();
        exit;
    }
    return true; //user is authorized
}
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Post by Christopher »

Here is my take on how it would work:

Code: Select all

// if user authenticates, use user is authorized
function authtools_quick_authorize($continue_execution = false)
{
    $controller = new AuthTools_AuthController();

    // give the credentials to the auth controller
    $credentials = new AuthTools_Credentials_Auto();
    $controller->setCredentials($credentials );

    // likewise we need some to check the credentials against
    $controller->setDatasourceGateway($adapterObjectForMyUserDatabase);

    $is_authenticated = $controller->isAuthenticated();

//    $is_authorized != $is_authenticated because authenticated only 
//    means that the credentials given match those in the known datasource.
//    Some kind of user data (group, role, permissions, etc.) would 
//    need to be given to the Access Control system (not included
//    here) in order for the request to be authorized

    if (!$is_authenticated ) {
        $form = new AuthTools_BasicForm($auth_status);
        echo $form->getContents();
        exit;
    } else {
        // now we need to register this account with the Access Control system
        $access = new AuthTools_AccessController();

        // we need some session support
        $access->setPersistenceGateway($adapterObjectForMySessionSystem);

        // finally give the access controller the data it needs to allow/deny access 
        // for this authenticated session
        $access->register($adapterObjectForMyUserDatabase);
    }
    return true; //user is authenticated 
}
I don't deal with where $adapterObjectForMyUserDatabase and $adapterObjectForMySessionSystem come from in this example .
Last edited by Christopher on Sun May 21, 2006 10:13 pm, edited 1 time in total.
(#10850)
santosj
Forum Contributor
Posts: 157
Joined: Sat Apr 29, 2006 7:06 pm

Post by santosj »

Ambush Commander wrote: Even remember me could be auto-detected, even though we have agreed that it is a plugin. Maybe we should also have an AuthTools_Controller_Full which loads all plugins... Hmmm... Plugins cause interesting packaging problems. What about installing new packages? I'd rather have all the code just sitting around, ready to be used, but not parsed/included.
It is possible to detect the existance of whether of predefined class exists or not. We just have to specify how we are going to handle the 'plugable' classes. Do we want or need to have plugable classes? I believe that other developers would be able to get into the system more if they knew it was a simple process to add new elements.

That is what I was trying to get across with the AuthForm code. If you wanted to use it, you just plug it in. If you don't want to use it, then there is not a need to do so. I like the idea of plugin code as it gives me even more control. I could use the other dependent classes of the main Auth class to create my own implementation or extend the original class (which is sort of the same thing).

It would be longer but the Auto class is possible along with the manual one, or any one inbetween. We could create both or many classes and reference the one that the developer will most likely need.
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Post by Christopher »

I'm not sure that we need plugins yet as most of what is necessary are adapters to common functionality like the session or datasource.
(#10850)
Post Reply