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 »

If you don't want to use Sessions then you just don't use the Session Class, right? The AuthTools already has that flexiblity.

You don't have to build one class to fit to the minimum simple requirements because it isn't going to fit to most people's requirements. There should be multiple implementations for different tasks and lets make the assumption that the coder will be intelligent enough to choose the right one.
User avatar
Ambush Commander
DevNet Master
Posts: 3698
Joined: Mon Oct 25, 2004 9:29 pm
Location: New Jersey, US

Post by Ambush Commander »

If you don't want to use Sessions then you just don't use the Session Class, right? The AuthTools already has that flexiblity.
Well, technically, by default, sessions would be initialized (It's not AuthTools_Session_Auto for nothing). But we're talking about code that doesn't exist.
You don't have to build one class to fit to the minimum simple requirements because it isn't going to fit to most people's requirements. There should be multiple implementations for different tasks and lets make the assumption that the coder will be intelligent enough to choose the right one.
The minimum simple class, however, serves as not only example code but also something they can extend their own class off of.
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Post by Christopher »

[quote='santosj"]If you don't want to use Sessions then you just don't use the Session Class, right? The AuthTools already has that flexiblity. [/quote]
Exactly.
Ambush Commander wrote:Well... if the authentication isn't "sticky" (it only applies for one request), then yeah, it doesn't need a session. But if you want to "log in" in the conventional sense, sessions (or, at the very least, some type of cookie) is needed.
Actually you need a session after you "log in" in the conventional sense. I have been using the name Access Control for everything after your credentials are authenticated. There is a bunch of stuff that Access Control part -- but it is separate.

Scenarios:

1. You want to authenticate a Captcha but you don't want any other access controls: +authenticate / -access controls

2. You want run the access control code in the front controller (all pages) but have "allow all" on most pages: -authenticate / +access control

3. You have to login (authenticate) to access Admin pages with access controls: +authenticate / +access controls

The question for me on #3 is how we transition from $auth->isAuthenticated() == true to get to $access>isAuthorized() == true? We obviously need to initialize the access control manager with some data that the authentication manager probably just had.[/b]
(#10850)
santosj
Forum Contributor
Posts: 157
Joined: Sat Apr 29, 2006 7:06 pm

Post by santosj »

Ambush Commander wrote:Well, technically, by default, sessions would be initialized (It's not AuthTools_Session_Auto for nothing). But we're talking about code that doesn't exist.

The minimum simple class, however, serves as not only example code but also something they can extend their own class off of.
Why would you initialize the Session when it isn't needed? In the example of the captcha and you are a guest, you just fill the captcha and the session is destroyed so why create it in the first place. You wouldn't want to use the authorization from a single captcha if they aren't signed in. In case a bot DID get lucky it would have unlimited access to flood your blog posts unhindered. You want the bot to have to try to input a captcha as well as visitor. How many times are they really going to post a comment?

If a person is going to extend it they would just remove the session code. How about if the session adapter isn't inputted then it isn't used and the session isn't created?
User avatar
Ambush Commander
DevNet Master
Posts: 3698
Joined: Mon Oct 25, 2004 9:29 pm
Location: New Jersey, US

Post by Ambush Commander »

Okay, stop. Wait. I thought we were authenticating users, not captchas.

You don't verify the "identity" of a "captcha." Any captcha verification systems would be independent of our framework?

I don't understand where captcha came into the equation.
The question for me on #3 is how we transition from $auth->isAuthenticated() == true to get to $access>isAuthorized() == true?
If a user is not authenticated, we don't know their identity, therefore, they're anonymous. Authorization is a piece of cake: is the resource allowed to be accessed by anonymous users? If they are authenticated, we know who they are, thus, we have their user id, which we can use to determine access. getUserID()
Why would you initialize the Session when it isn't needed?
I wouldn't. The session would be initialized after a user logs in, not when an anonymous user comes by.
If a person is going to extend it they would just remove the session code. How about if the session adapter isn't inputted then it isn't used and the session isn't created?
Well, if they're using totally different, I'd expect them to use the interface. But if they wanted to augment the session adapter...
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:Okay, stop. Wait. I thought we were authenticating users, not captchas.

You don't verify the "identity" of a "captcha." Any captcha verification systems would be independent of our framework?

I don't understand where captcha came into the equation.
I don't see the difference between a Captcha and a user account. In both cases a known credential is created and the user is challenged to provide the known credential. It doesn't matter whether the lifespan of the credential is for the current request, a day, a month or a year. All the authentication system cares about is matching one or more credentials from the request with one or more known credentials in its Datasource. If there is a match -- authenticated.

With Captcha the datasource is the session and a new credential is created every request. With a standard user account the datasource is a database and the User ID/Password are created by the user or an administrator.

So my question was: if the the Access Control system is used after Authentication, how is the User ID passed forward? Is there a corresponding $access->setUserID() for your $auth->getUserID() ? And what about any other applicable data that the Authentication manager happens to currently have -- that would save a redundant access to the datasource?
(#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 don't see the difference between a Captcha and a user account. In both cases a known credential is created and the user is challenged to provide the known credential. It doesn't matter whether the lifespan of the credential is for the current request, a day, a month or a year. All the authentication system cares about is matching one or more credentials from the request with one or more known credentials in its Datasource. If there is a match -- authenticated.

With Captcha the datasource is the session and a new credential is created every request. With a standard user account the datasource is a database and the User ID/Password are created by the user or an administrator.
Okay, I can't agree with that. At least, not within the scope of our current discussion. Let's first consider what a captcha is:

Captcha - A CAPTCHA is a type of challenge-response test used in computing to determine whether or not the user is human.

Where does "authentication" or "credential" come into the definition?

Credential - that which entitles one to confidence, credit, or authority. In our case, it's authentication (perhaps credential isn't a good term for it).

Authentication - the verification of the identity of a person or process. In a communication system, authentication verifies that messages really come from their stated source, like the signature on a (paper) letter.

So where's the confusion? In this case, we're taking "credential" to mean something that must be matched against a known source in the website (to, according to our definition, make the system recognize you as a valid user). This definition seems perfectly valid until you add the parentheses. A captcha is not meant to act as a credential in order to authenticate you as someone it knows about. A captcha is meant to distinguish a user from a bot.

That's why anonymous users can use Captchas without having an account.

Admittedly, matching user-supplied input to a known datasource to verify "something" is a common problem between the two, but in the context of Authentication, there is no reason why the AuthManager should be able to "verify the validity of a CAPTCHA".
So my question was: if the the Access Control system is used after Authentication, how is the User ID passed forward? Is there a corresponding $access->setUserID() for your $auth->getUserID() ?
I would expect so. The reason we're not passing user ids around, however, is because there might be other information the authentication manager has (such as which credentials were used to authorize a user), so the best idea is to make the manager itself globally available.
And what about any other applicable data that the Authentication manager happens to currently have -- that would save a redundant access to the datasource?
This data is different from "which credentials were used to authorize a user". In the former case, we're talking about extra, request-specific info. In this case, we're talking about cached data. I would imagine a caching layer would make most sense to be transparently built into the datasource/session, so that the authentication manager itself doesn't know about it. So yes, the datasource may need to know about the session (though isn't that what a session is: another datasource?)
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:Captcha - A CAPTCHA is a type of challenge-response test used in computing to determine whether or not the user is human.
I agree AC. All the CAPTCHA does is authenticate the known challenge with the given response. This is not authentication of identity, but authentication of matched data at the user interface level. The Authentication the app is concerned (as I understand it) is the validating of information supplied by the user as it relates to information known by the system for the purpose of determining authorization and access control levels. CAPTCHA is a nice feature to prevent spam bots from working there way through a form, but I don't think it should be considered a means or method to authentication. Just my opinion.
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Post by Christopher »

My point here is that if all that our Authentication Manager did was validate credentials provided to it against a known datasource -- that would be a good thing. Especially if we defined some clear conventions and interfaces. It would keep it focused and multi-purpose. You can always extend a more generic class to make is more specific, but not the other way.

I think you guys are getting ahead of yourselves and into the rest of the Access Control system. I really think the authenticator should just authenticate and then communicate its status to the rest of the system.
(#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 understand now. You're trying to abstract the problem even more, sort of what I was talking about when I mentioned that the core problems of both captchas/authentication are the same.

I have no problem abstracting that out. It might reduce duplication when we need to add in Captcha functionality. However, I think that just validating credentials is a far too narrow definition of authorization. They're not equivalent, and I don't think narrowing this component's scope will help much with usability or understandability. If we do create a more abstract class, it definitely wouldn't be named AuthenticationManager.

Edit - Haha, said Authorization when I meant Authentication.
Last edited by Ambush Commander on Thu May 25, 2006 7:07 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 »

arborint wrote:My point here is that if all that our Authentication Manager did was validate credentials provided to it against a known datasource -- that would be a good thing. Especially if we defined some clear conventions and interfaces. It would keep it focused and multi-purpose. You can always extend a more generic class to make is more specific, but not the other way.

I think you guys are getting ahead of yourselves and into the rest of the Access Control system. I really think the authenticator should just authenticate and then communicate its status to the rest of the system.
I agree.
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 have no problem abstracting that out. It might reduce duplication when we need to add in Captcha functionality. However, I think that just validating credentials is a far too narrow definition of authorization. They're not equivalent, and I don't think narrowing this component's scope will help much with usability or understandability. If we do create a more abstract class, it definitely wouldn't be named AuthorizationManager.
I agree completely. And I think Authorization is out next step. But we need to wrap up Authentication which is the current step. Here is my proposal. We create an Authenticator class that accepts two object: a Credential and a AuthenticationDatasource. We define interfaces to those two objects or create abstract adapter classes. We just to a quick first version that we think is close. Then we create three example implementations:

1. A standard HTML form login page (username/password) that gets credentials from POST and checks it against a simple "database" (it could be SQLite, MySQL, or better still just a mocked Gateway class with an array of user records),

2. A Remember Me example that gets credentials from COOKIE and checks a Datasource object created by the application

3. A Captcha example that generates a "password" saves it in a session based datasource and then gets the password from POST

We learn from the implementations, improve the Authenticator, Credential, AuthenticationDatasource to get to an alpha state, and then more on to Authorization.


PS - You can see why I hate using the terms Authorization and Authentication in the same sentence -- its 'auth' and 'auth' and I have a hard time keeping track.
(#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 don't like it, but I'll play along.

Can we first decide on a new name for this "authentication" of captchas? Because I still don't agree that, in the traditional sense, "authentication" means what you're describing. Perhaps recognition? Furthermore, I don't think "Credential" is the right way to describe a "Captcha".

Plus, we're pushing out certain things that must be done to have a fully featured "Auth" system, namely speaking, managing the different types of credentials. Furthermore, recognizing a credential isn't always as simple as an equality check. Passwords, for example, should be stored in the database as a salted hash. The specific recognizer would have to handle hashing, salt retrieval, etc. Other layers, such as client side challenge/response and assymetric encryption requires more manipulation with the credential before it can be recognized (I keep on wanting to say verified, but that's a very general term).

That being said, I think that the interface might look like this...

Code: Select all

<?php

interface AuthTools_Recognizer_Interface
{
    function setDataAdapter($data_adapter); // includes read-only session data
    function recognize($recognizable_data); // like a credential
}

?>
PS - on further thinking, this might be a good idea. But please don't call it authentication... it will confuse the heck out of a lot of people (including me)
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 don't like it, but I'll play along.
I have been pushing a little on this, but honestly this need to be your spec so move forward as you think is best because it needs to be someone's baby and in this thread it is yours. :)

I have stated that I really dislike these terms because they have confused every converstation I have ever had that used them. Read this entry on Authentication because I think it covers the nuance well. They even use the terms A1 and A2 to try to clarify. For me the key is this:

However, more precise usage describes authentication as the process of verifying a person's identity, while authorization is the process of verifying that a known person has the authority to perform a certain operation. Authentication, therefore, must precede authorization. For example, when you show proper identification to a bank teller, you could be authenticated by the teller, and you would be authorized to access information about your bank acccounts. You would not be authorized to access accounts that are not your own.

And I really don't see the difference between Captcha and a user accounts. In both cases you are providing a credential to a group that meet a certain requirement -- whether that requirement is "employee of company" or "can read characters in graphics" it does not really matter. You are giving out credentials to limit access in both cases. And you are do so in a way that is selective. But most importantly the software process for each authentication is identical.
Ambush Commander wrote:Plus, we're pushing out certain things that must be done to have a fully featured "Auth" system, namely speaking, managing the different types of credentials. Furthermore, recognizing a credential isn't always as simple as an equality check. Passwords, for example, should be stored in the database as a salted hash. The specific recognizer would have to handle hashing, salt retrieval, etc. Other layers, such as client side challenge/response and assymetric encryption requires more manipulation with the credential before it can be recognized (I keep on wanting to say verified, but that's a very general term).
I think our challenge at this step is to create an Authorizer class that is flexible to handle a broad specturm of use cases ... and that we create interfaces that make is fairly easy and straightforward to create the adapters necessary to inteface with their system.
(#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 »

Read this entry on Authentication because I think it covers the nuance well. They even use the terms A1 and A2 to try to clarify.
Heh, I wouldn't totally trust Wikipedia's article. That sentence was added in by an anonymous user.
authentication as the process of verifying a person's identity
This is precisely why we cannot use authentication to name the process you describe. Authentication is very narrow: it's verifying identity. A captcha is verifying something different: whether or not the user is human.

Being verification in order to establish identity is the difference.

And no, identity (the user is Bob (which, in isolation, is quite meaningless)) is not equivalent to a broad group (the user can read distorted words).

As for authentication and authorization, I am about to snap and declare the use of these two words forbidden forever.

I need some code. ::stalks off::

Edit - Okay. I backtracked in the thread, read some of Arborints responses, and I have decided that we can no longer use "Authentication" as a term.

Authentication asks two questions:
1. Is this person really who he says it is? (my def) which is a subset of
2. Is the data/credential valid/genuine? (Arborint's def)

Credential means two things:
1. A piece of information that establishes the identity of a user (my def) which is a subset of
2. A piece of information that establishes confidence in a certain assertion (Arborint's def)

Now... we need some replacement words.

Edit 2 - Hey, would you mind going on IRC for a little bit to chat this out a bit and figure it out?
Post Reply