I set up a Zend_Acl and Zend_Auth scheme where user is authenticated using Zend_Auth_Adapter_Ldap and stored in session. I use a controller plugin to check if $auth->hasIdentity() and $acl->isAllowed() to display login form if needed.
What I want to do is to add login cookies (my implementation of best practices), and API keys in addition to the session check in Zend_Auth. I also need to switch the role to 'owner', on content created by the user.
My concerns:
Login cookie should only be used as fallback if regular session auth fails, and thus the session should be authenticated
API keys should be used as fallback if both login cookie and session cookie fails
I don't want to store the password anywhere, it should only reside in LDAP
I need persistent storage of the identity, as looking it up in LDAP is not possible without full username and password
The role is dependent both on LDAP group membership (which needs to be persistently stored), and if the identity should be considered owner of the content (meaning it's changing in between requests, unless admin)
What's a good pattern / approach to solve this using Zend Framework MVC and Zend_Auth + Zend_Acl ?
you can create your own adapter/storage classes, with implementing Zend_Auth_Adpater_Interface and Zend_Auth_Storage_Interface
In these classes, you can re-use original adapters (like LDAP) or storages, and only write the code that implements your auth rules.
for example, using multiple sources for the Zend_Auth_Adapter :
<?php
class My_Auth_Adapter implements Zend_Auth_Adapter_Interface
{
private $ldapAdapter;
private $cookieAdapter;
private $apiKeyAdapter;
public function __construct($ldapAdapter, $cookieAdapter, $apiKeyAdapter) {
{
$this->ldapAdapter = $ldapAdapter;
$this->cookieAdapter = $cookieAdapter;
$this->apyKeyAdapter = $apiKeyAdapter;
}
public function authenticate()
{
if ($this->ldapAdapter->authenticate()) {
//return the Zend_Auth_Restult
} elseif ($this->cookieAdapter->authenticate() {
//return the result
} elseif ($this->apiKeyAdapter->authenticate() {
//return the result
} else {
//Create and return a Zend_Auth_Result which prevents logging in
}
}
}
I am not sure to understand your login rules, but the concept remains the same for the Storage class :
<?php
class My_Auth_Storage implements Zend_Auth_Storage_Interface
private $sessionStorage;
private $cookieStorage;
private $apiStorage;
public function read()
{
if (!$this->sessionStorage->isEmpty())
{
return $this->sessionStorage->read();
} elseif (!$this->cookieStorage->isEmpty())
{
return $this->cookieStorage->read();
} //And so one, do not forget to implement all the interface's methods
With this implementation, you can have multiple credential sources, and multiple session storage engines (cookie, session, db, or whatever you want to use).
For your acl concerns, you can fetch the LDAP group in you controller plugin and store it wherever you need, after authentication. You can then use a second plugin that checks ACLs on each request.
Related
I am building a new Laravel application (v5.4) that will run alongside (installed in the same environment) an existing PHP application that has it's own authentication system. I want the users who have successfully logged in to the existing system to be automatically authenticated in the Laravel app so they can navigate seamlessly between the applications.
My Laravel app has read-only access (through a second db connection) to the existing system's database so it can safely check that the PHP Session matches the session cookie recorded in the database and I can even pull out the user object and hand it to Auth's login() method.
I want to know the best way to put Auth into an authorised state (not guest) and where is the best place to put such code?
Options I've thunked of so far:
Middleware: Check session and call the login() method on Auth from some application-wide middleware?
Extend Illuminate/Auth/SessionGuard.php and override the attempt() method? If so, how do I tell the other parts to use my extended SessionGuard? (I suspect this was not designed to be easily overridden)
Super hacky disgusting way of dynamically setting the user's password to a random hash and then calling Auth/LoginController#login() in the background with a faked request containing that hash as the password field. (I seriously hope this doesn't end up being the most popular answer)
Some other option (?)...
Thanks in advance for your help SO community!
The solution I ran with in the end was creating a middleware that contains this:
if (session_status() == PHP_SESSION_NONE) {
session_start();
}
if (isSet($_SESSION['intranet_user_id']) && $_SESSION['intranet_user_id']) {
// Log them in manually
$intranet_user_id = $_SESSION['intranet_user_id'];
if (!Auth::guest() && Auth::user()->getId() !== $intranet_user_id ) {
Auth::logout();
}
if (Auth::guest()) {
Auth::login( User::find($intranet_user_id), true);
}
} else {
Auth::logout();
}
Case: I'm building a forum using Laravel's Authorization as a backbone using policies. Examples of checks I run are stuff like #can('view', $forum), and #can('reply', $topic), Gate::allows('create_topic', $forum) etc. These checks basically checks if the users role has that permission for the specific forum, topic or post. That way I can give roles very specific permissions for each forum in my application.
The issue is that all of these checks go through the Gate class, specifically a method called raw() which in its first line does this:
if (! $user = $this->resolveUser()) {
return false;
}
This presents an issue when dealing with forums. Guests to my application should also be allowed to view my forum, however as you can see from the code above, Laravels Gate class automatically returns false if the user is not logged in.
I need to be able to trigger my policies even if there is no user. Say in my ForumPolicy#view method, I do if(User::guest() && $forum->hasGuestViewAccess()) { return true }
But as you can see, this method will never trigger.
Is there a way for me to still use Laravel's authorization feature with guest users?
I'm not aware of a super natural way to accomplish this, but if it's necessary, you could change the gate's user resolver, which is responsible for finding users (by default it reads from Auth::user()).
Since the resolver is protected and has no setters, you'll need to modify it on creation. The gate is instantiated in Laravel's AuthServiceProvider. You can extend this class and replace the reference to it in the app.providers config with your subclass.
It's going to be up to you what kind of guest object to return (as long as it's truthy), but I'd probably use something like an empty User model:
protected function registerAccessGate()
{
$this->app->singleton(GateContract::class, function ($app) {
return new Gate($app, function () use ($app) {
$user = $app['auth']->user();
if ($user) {
return $user;
}
return new \App\User;
});
});
}
You could go a step further and set a special property on it like $user->isGuest, or even define a special guest class or constant.
Alternatively you could adjust your process at the Auth level so that all logged-out sessions are wrapped in a call to Auth::setUser($guestUserObject).
I just released a package that allows permission logic to be applied to guest users. It slightly modifies Laravel's Authorization to return a Guest object instead of null when no user is resolved. Also every authorization check now makes it to the Gate instead of failing authorization instantly because there isn't an authenticated user.
I'm learning PHP, and I'm curious if there are elegant solutions to designing an authentication interface for a website.
Basically, I will have three types of users: Regular Users, Admins, and "Power users".
each type of user will have its own actions.
Here is a brief sketch of my current code:
# Regular User = Non-Authenticated
interface IRegularUser {
# Will return an object of a class that implements this interface
public static function loginUser ($name, $pass);
}
# Authenticated User
class AuthUser extends RegularUser {
public function logoutUser();
}
interface IAdmin {..}
interface IPowerUser {...}
class User implements IRegularUser {}
class Admin extends AuthUser implements IAdmin {}
class PowerUser extends AuthUser implements IPowerUser {}
In the script that checks for correct login, I would write something similar to this:
$user = new User();
$user = $user->loginUser($_POST['username'], $_POST['password']);
if (get_class($user) == get_class(new Admin()))
# Redirect to admin_home.html
else if (get_class($user) == get_class(new PowerUser()))
# Redirect to power_user_home.html
I am trying to use the OOP features of PHP, in order to establish some constraints between the entities in my application (Ex: Only by acquiring an User object, you can then login, and acquire an object of type Admin, or PowerUser).
I feel that my authentication system is kind of clunky, and I would like to know if there is a common design pattern for a webapp authentication system.
Actually, its not that easy as it seems at first glance. There are 3 different aspects when dealing with users, that have roles. The "system" you're looking for would consists of these components:
Query adapter
Its responsible for finding records match against some adapter. This can query against almost any type, be it MySQL table, XML file or Mongo DB collection. All your query adapters would implement this interface:
interface QueryAdapter
{
public function recordValid($username, $password);
}
Access Control List (ACL/RBAC)
It must be separated layer, that deals with roles and their permissions. Typically
$roleManager = new RoleManager();
$roleManager->register(array(
'admin' => 'write, edit, read, delete',
'user' => 'view',
'moderator' => 'write, edit, read'
));
$currentUser = get_that_from_session();
if ($roleManager->isAllowed($currentUser, 'write')) {
// Allow writing
} else {
echo 'You are not allowed to write';
}
Storage adapter
That is responsible for storing passwords and tokens inside either $_SESSION or $_COOKIE. If user clicked on Remember me, then you would store that info inside $_COOKIE, otherwise in $_SESSION.
Typical workflow
To "connect" them all together, you would write it like this : (Keep in mind, this is extremely simplified version of it)
<?php
$queryAdapter = new Query_Adapter_MySQL($pdo); // or $mongo, whatever
if ($queryAdapter->rowExists($_POST['username'], $_POST['password'])) {
$role = $queryAdapter->getRole(); // Let's assume that its "user"
$roleManager = new RoleManager();
$roleManager->register(array(
$role => 'read'
));
if (isset($_POST['rememberMe'])){
$storageAdapter = new StorageAdapter_Cookie();
} else {
$storageAdapter = new StorageAdapten_Session();
}
$storageAdapter->write(array(
'role' => $role,
'passwordHash' => $passwordHash,
'token' => $token
));
}
To check if that user logged in, and has a right to do something, you would simply query an adapter to sees that, like,
<?php
if ($storageAdapter->isLoggedIn()){
if ($roleManager->hasRight($storageAdapter->get('role'), 'read')){
// Allowed to read content
}
}
What would you gain with this approach?
Clear separation of responsibilities (This adheres to Single-Responsibility Principle)
Improved code readability
Adhering to Dependency Injection (thus making unit-testing possible)
You can easily switch from MySQL to another storage, without affecting the rest of your code. You would simply inject an instance of the adapter you're going to use.
Is that it?
Yes. You can also take a look at how Zend Framework implements this
I need a solution where authenticated users are allowed access to certain Controllers/Actions based not on their user type :ie. admin or normal user (although I may add this using standard ACL later) but according to the current status of their user.
For example :
Have they been a member of the site for more than 1 week?
Have they filled in their profile fully?
Actually, now that I think about it, kind of like they have on this site with their priviledges and badges.
For dynamic condition-based tests like you are describing, you can use dynamic assertions in your Zend_Acl rules.
For example:
class My_Acl_IsProfileComplete implements Zend_Acl_Assert_Interface
{
protected $user;
public function __construct($user)
{
$this->user = $user;
}
public function assert(Zend_Acl $acl,
Zend_Acl_Role_Interface $role = null,
Zend_Acl_Resource_Interface $resource = null,
$privilege = null)
{
// check the user's profile
if (null === $this->user){
return false;
}
return $this->user->isProfileComplete(); // for example
}
}
Then when defining your Acl object:
$user = Zend_Auth::getInstance()->getIdentity();
$assertion = new My_Acl_Assertion_IsProfileComplete($user);
$acl->allow($role, $resource, $privilege, $assertion);
Of course, some of the details depend upon the specifics of what you need to check and what you can use in your depend upon what you store in your Zend_Auth::setIdentity() call - only a user Id, a full user object, etc. And the roles, resources, and privileges are completely app-specific. But hopefully this gives the idea.
Also, since the assertion object requires a user object at instantiation, this dynamic rule cannot be added at Bootstrap. But, you can create the core Acl instance with static rules during bootstrap and then register a front controller plugin (to run at preDispatch(), say) that adds the dynamic assertion. This way, the Acl is fully populated by the time you get to your controllers where presumably you would be checking them.
Just thinking out loud.
I was hoping someone could help me with a question I've come up on.
I have a Session object that handles storage of general session data, I also have a Authentication object which validates a users credentials.
Initially I passed the desired Authentication class name to my Session object then had a login method that created an instance of the Authentication object and validate the credentials. I stored the result of this validation in a Session variable and made it available via a getter. The user data was also stored in the Session for later use. In addition to all this, I have a logout method, which removes the user data from the Session and thus logging the user out.
My question is what role should the Session object play in users logging into their account?
And what other ways might one suggest I go about handling user login, as it stands right now I feel as though I'm getting too much wrapped up in my Session object.
Simply calling your authenticate method should trigger logic within Auth to store the proper data in the session (or some other data store) and Auth should also be used exclusively to retreive/revoke this info. So using the example form your comment it might be:
class Auth {
public static function authenticate($identity, $pass)
{
// do lookup to match identity/pass if its good then
/* assume $auth is an array with the username/email or
whatever data you need to store as part of authentication */
Session::set('auth', $auth);
return true;
// if auth failed then
Session::set('auth', array('user'=>'anonymous'));
return false;
}
public function isAuthenticated()
{
$auth = Session::get('auth');
if(!$auth)
{
return false;
}
return (isset($auth['user']) && $auth['user'] !== 'anonymous');
}
}
[...] as it stands right now I feel as
though I'm getting too much wrapped up
in my Session object.
And id agree. Idelaly for authentication/credentials you shoudl only be interacting with the Auth/Acl object(s). They would then utilize the session as stateful store... but you shouldnt care that its even stored in session. The code utilizng the Auth/Acl object(s) should be completely unaware of this fact.
For example:
//Bad
if($session->get('authenticated', 'auth'))
{
// do stuff
}
// also bad
if(isset($_SESSION['authenticated']))
{
// do stuff
}
//Good
if($auth->isAuthenticated())
{
// do stuff
}
// inside $auth class it might look like this
public function isAuthenticated()
{
$store = $this->getSotrage(); // assume this returns the $_SESSION['auth']
return isset($store['authenticated']);
}
The session is a good place for holding user data that you want to have managed in some sort of state across various pages or if you need a fast accessible way to get at it without hitting the database. It is a bad idea to keep secure information (re: passwords/etc) in the session, but rapid access information like username, name, email address, preferences, etc is all good data to put in the session. Try to keep it simple though.
Keep in mind though, that the session (or related cookie) should only ever be used for identification. It should not be used for authentication.
Authentication object is a good method. Make sure that it only holds secure information as long as it needs to and that it has all the necessary functions available to keep sensitive data protected.