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

User avatar
Nathaniel
Forum Contributor
Posts: 396
Joined: Wed Aug 31, 2005 5:58 pm
Location: Arkansas, USA

Post by Nathaniel »

Mk, that looks pretty clean to me as well.

I agree with Commander's comments concerning the interfaces and whether or not an interface has _Interface in the name: it is way too confusing, and certainly not obvious. That's ok, we can iron it out.
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Post by Christopher »

I am of two minds about this. If we proceed with having the Session Adapter given to the Authentication Manager then it we would probably carry that object forward to provide to the Authorization/Access Control Manager.

But that obviously leads us to the question of whether the Session Adapter needs to get involved with the Authentication Manager at all. It really doesn't need to. In fact the simplest cases of Authentication does not need to be persisted -- such as providing a Captcha along with a blog/forum post or some other form.

What if we moved all that to the Authorization/Access Control Manager.

Code: Select all

interface AuthTools_Interface_AuthenticationManager
{
    public function setCredentials();
    public function setDataAdapter();
   
    public function authenticateUser($type = false);
    public function isUserAuthenticated($type = false);
}


interface AuthTools_Interface_AccessManager
{
    public function setAuthorizationAdapter();
    public function setSessionAdapter();
   
    public function checkAccess($type = false);
    public function hasAccess($type = false);
}

class AuthTools_DataAdapter_AutoMySQL implements AuthTools_DataAdapter {}
class AuthTools_Credentials_AutoGroups implements AuthTools_Credentials {}

class AuthTools_SessionAdapter_Auto implements AuthTools_SessionAdapter {}
class AuthTools_AuthorizationAdapter_AutoGroups implements AuthTools_AuthorizationAdapter {}
We still need some way to get the data we need from the DatasourceAdapter to the SessionAdapter.
(#10850)
santosj
Forum Contributor
Posts: 157
Joined: Sat Apr 29, 2006 7:06 pm

Post by santosj »

I think that the 'Interface should be at the end instead of in front of.

Code: Select all

interface AuthTools_AccessManager_Interface { }

interface AuthTools_AuthenticateManager_Interface { }
As you can see it is easier to group classes with their interface as you are not going to do this.

Code: Select all

class AuthTools_Class_AccessManager implements AuthTools_Interface_AccessManager { }
You would want do this

Code: Select all

class AuthTools_AccessManager implements AuthTools_AccessManager_Interface { }
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 that the 'Interface should be at the end instead of in front of.
I understand what you're getting at. I wrestled with the decision, and figured that since we emulate directory structure by class name (we're going to have very logical naming conventions: a class named AccessManager_Interface will be located in AccessManager/Interface.php) and thus the problem. Interface/AccessManager.php seems more manager, and, plus, they're all lumped together for convenience. But I can still be convinced. (and, of course, we can always vote on it)
What if we moved (sessions) to the Authorization/Access Control Manager(?)
Umm... did you read my other post? Sessions are an intrinsic part of authentication.
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Post by Christopher »

As far as where things should go and specific naming, please sort it out. I just slapped that code up as a discussion point.
Ambush Commander wrote:Umm... did you read my other post? Sessions are an intrinsic part of authentication.
I read it . My question is are the two sessions being discussed the same thing. You talk about some specialized authentication systems needing persistent storage. They can certainly do that. But I am not sure that that has anything to do with the persistent store for the authorization/access control system. I am assuming that once authenticated then the authorization/access control system takes over and we don't need to re-authenticate each request.
(#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 »

My question is are the two sessions being discussed the same thing.
Maybe not. I'm not even sure what these two sessions are.
You talk about some specialized authentication systems needing persistent storage. They can certainly do that. But I am not sure that that has anything to do with the persistent store for the authorization/access control system. I am assuming that once authenticated then the authorization/access control system takes over and we don't need to re-authorize each request.
However, technically, you do. You're just authorizing them on basis of the session ID they're presenting.

I don't know if I'm understanding you... I'm talking about the "thing" (authentication sessions) that virtually every authentication system on earth has.
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 know if I'm understanding you... I'm talking about the "thing" (authentication sessions) that virtually every authentication system on earth has.
I think it is me not understanding you ... can you fully explain "authentication sessions"?
(#10850)
santosj
Forum Contributor
Posts: 157
Joined: Sat Apr 29, 2006 7:06 pm

Post by santosj »

arborint wrote:As far as where things should go and specific naming, please sort it out. I just slapped that code up as a discussion point.
Well, now I feel bad, arguing over nothing, but it does kind of raise a good point of naming convention.
I read it . My question is are the two sessions being discussed the same thing. You talk about some specialized authentication systems needing persistent storage. They can certainly do that. But I am not sure that that has anything to do with the persistent store for the authorization/access control system. I am assuming that once authenticated then the authorization/access control system takes over and we don't need to re-authorize each request.
Indeed, but I say that $_SESSION is a good persistent method since it is built-in and no other dependencies are needed. However, the default path should be changed for security reasons.
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:Well, now I feel bad, arguing over nothing, but it does kind of raise a good point of naming convention.
I find the naming already confusing as I have said above -- before adding class and file naming into the mix. I care less what the terms are than that were are all using the same terms.
santosj wrote:Indeed, but I say that $_SESSION is a good persistent method since it is built-in and no other dependencies are needed. However, the default path should be changed for security reasons.
I think we should be able to handle the spectrum from simple $_SESSION based code all the way up to more secure/specialized implementations. For the majority of sites, there is less concern about absolute security and more about access control functionality. We have twin goals of high potential security and making it easy to implement a farily complex access control system in a fairly easy manner.
(#10850)
santosj
Forum Contributor
Posts: 157
Joined: Sat Apr 29, 2006 7:06 pm

Post by santosj »

I find the naming already confusing as I have said above -- before adding class and file naming into the mix. I care less what the terms are than that were are all using the same terms.
Well, to be honest I use the 'Section/interface.php' method instead of placing all of the interfaces in one folder.
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 it is me not understanding you ... can you fully explain "authentication sessions"?
Okay.

HTTP is stateless. We need to establish, then, on each request, that we are user so-and-so. Transmitting the username and password each time is 1) infeasible for POST based logins and 2) insecure for HTTP basic. So we supplant these credentials with a different (temporary) credential: the session ID.

We could have easily supplanted this with a different cookie/name, but it makes the most sense: when you issue a cookie that expires when the browser closes, the cookie is called a "session cookie", regardless of whether or not it's handled by the $_SESSION array.

But, the point of the matter is that besides the authorization problem, authentication, too, utilizes sessions. In fact, authorization may not even need sessions at all (it doesn't need to maintain state between requests: it just needs to figure out whether or not that particular request is allowed).

But you maintain a "state" of "authentication". Thus cookie-based sessions. Otherwise, you'd be "logging" the user in on every request (which is what happens with HTTP basic authentication).

Naming conventions - We have to make a choice and stick to it. AuthTools_Interface_* or AuthTools_*_Interface?
User avatar
Nathaniel
Forum Contributor
Posts: 396
Joined: Wed Aug 31, 2005 5:58 pm
Location: Arkansas, USA

Post by Nathaniel »

I vote for AuthTools_*_Interace.
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 think it is me not understanding you ... can you fully explain "authentication sessions"?
Okay.
But I still don't see how Authentication has any need for a session. For example a simple post a reply on a blog system would check the Captcha value against its Datasourse (which might use PHP sessions) but that's the end if it -- no further Access Control. If you want further Access Control then once isAuthenticated() is true the rest of the Access Control system is initialized and takes over -- and it needs a session sub-system.
(#10850)
santosj
Forum Contributor
Posts: 157
Joined: Sat Apr 29, 2006 7:06 pm

Post by santosj »

Nathaniel wrote:I vote for AuthTools_*_Interace.
Second.
User avatar
Ambush Commander
DevNet Master
Posts: 3698
Joined: Mon Oct 25, 2004 9:29 pm
Location: New Jersey, US

Post by Ambush Commander »

But I still don't see how Authentication has any need for a session. For example a simple post a reply on a blog system would check the Captcha value against its Datasourse (which might use PHP sessions) but that's the end if it -- no further Access Control. If you want further Access Control then once isAuthenticated() is true the rest of the Access Control system is initialized and takes over -- and it needs a session sub-system.
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.
Post Reply