Page 11 of 20

Posted: Tue May 23, 2006 9:56 pm
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.

Posted: Tue May 23, 2006 10:12 pm
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.

Posted: Wed May 24, 2006 7:58 am
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 { }

Posted: Wed May 24, 2006 4:02 pm
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.

Posted: Wed May 24, 2006 4:20 pm
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.

Posted: Wed May 24, 2006 4:33 pm
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.

Posted: Wed May 24, 2006 4:38 pm
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"?

Posted: Wed May 24, 2006 4:43 pm
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.

Posted: Wed May 24, 2006 4:50 pm
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.

Posted: Wed May 24, 2006 4:58 pm
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.

Posted: Wed May 24, 2006 5:22 pm
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?

Posted: Wed May 24, 2006 5:23 pm
by Nathaniel
I vote for AuthTools_*_Interace.

Posted: Wed May 24, 2006 5:37 pm
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.

Posted: Wed May 24, 2006 5:43 pm
by santosj
Nathaniel wrote:I vote for AuthTools_*_Interace.
Second.

Posted: Wed May 24, 2006 5:45 pm
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.