Authentication Poll & Community Design [PLEASE JOIN!]
Moderator: General Moderators
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
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.
We still need some way to get the data we need from the DatasourceAdapter to the SessionAdapter.
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 {}(#10850)
I think that the 'Interface should be at the end instead of in front of.
As you can see it is easier to group classes with their interface as you are not going to do this.
You would want do this
Code: Select all
interface AuthTools_AccessManager_Interface { }
interface AuthTools_AuthenticateManager_Interface { }Code: Select all
class AuthTools_Class_AccessManager implements AuthTools_Interface_AccessManager { }Code: Select all
class AuthTools_AccessManager implements AuthTools_AccessManager_Interface { }- Ambush Commander
- DevNet Master
- Posts: 3698
- Joined: Mon Oct 25, 2004 9:29 pm
- Location: New Jersey, US
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)I think that the 'Interface should be at the end instead of in front of.
Umm... did you read my other post? Sessions are an intrinsic part of authentication.What if we moved (sessions) to the Authorization/Access Control Manager(?)
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
As far as where things should go and specific naming, please sort it out. I just slapped that code up as a discussion point.
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.Ambush Commander wrote:Umm... did you read my other post? Sessions are an intrinsic part of authentication.
(#10850)
- Ambush Commander
- DevNet Master
- Posts: 3698
- Joined: Mon Oct 25, 2004 9:29 pm
- Location: New Jersey, US
Maybe not. I'm not even sure what these two sessions are.My question is are the two sessions being discussed the same thing.
However, technically, you do. You're just authorizing them on basis of the session ID they're presenting.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.
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.
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
Well, now I feel bad, arguing over nothing, but it does kind of raise a good point of naming convention.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.
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 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.
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
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:Well, now I feel bad, arguing over nothing, but it does kind of raise a good point of naming convention.
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.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.
(#10850)
Well, to be honest I use the 'Section/interface.php' method instead of placing all of the interfaces in one folder.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.
- Ambush Commander
- DevNet Master
- Posts: 3698
- Joined: Mon Oct 25, 2004 9:29 pm
- Location: New Jersey, US
Okay.I think it is me not understanding you ... can you fully explain "authentication sessions"?
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?
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
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.Ambush Commander wrote:Okay.I think it is me not understanding you ... can you fully explain "authentication sessions"?
(#10850)
- Ambush Commander
- DevNet Master
- Posts: 3698
- Joined: Mon Oct 25, 2004 9:29 pm
- Location: New Jersey, US
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.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.