ARK2/Security - Revision history

John Layt: /* User Levels */

2018-04-09T10:11:55Z

‎User Levels

John Layt at 10:10, 9 April 2018

2018-04-09T10:10:56Z

John Layt: /* RBAC Model */

2016-12-30T11:21:19Z

‎RBAC Model

John Layt: /* RBAC Model */

2016-11-21T21:32:41Z

‎RBAC Model

John Layt: /* RBAC Model */

2016-11-21T21:30:55Z

‎RBAC Model

John Layt: /* RBAC Model */

2016-11-20T23:05:03Z

‎RBAC Model

John Layt: /* Security */

2016-11-20T21:24:40Z

‎Security

John Layt: Created page with "= Security = ARK currently uses PEAR LiveUser for user authentication and authorisation, but this hasn't been updated since 2010. It is a security risk, and also lacks many f..."

2016-10-30T14:25:14Z

Created page with "= Security = ARK currently uses PEAR LiveUser for user authentication and authorisation, but this hasn't been updated since 2010. It is a security risk, and also lacks many f..."

New page

= Security =

ARK currently uses PEAR LiveUser for user authentication and authorisation, but this hasn't been updated since 2010. It is a security risk, and also lacks many features like federated login. The ARK API currently uses plain text user and password in the request URL which is insecure. ARK2 will require a new security solution, especially for the API calls from client apps.

Requirements
* User Authentication
** Token-based
** Local user database for stand-alone/internal use
** Via OAuth and OpenID authentication services (Google, Facebook, etc)
* User Authorisation
** Role-Based Access Control (RBAC) model based on Users/Roles/Permissions
* API authentication via token and secure login
** HTTPS will be required
** Use LetsEncrypt to obtain SSL certificates
* Anonymous/Unauthenticated User access as optional Role for both Web and API
* A migration path from LiveUser must be provided.

Any solution chosen will work best when integrated with the other framework components chosen and should be implemented in parallel as it is highly dependent on the Request/Response/Routing/Session components used.

The Symfony Framework provides a very powerful Security component, but not a simple all-in-one solution meeting our requirements. Combining a number of external components may be able to meet our requirements, at the cost of more custom code required.
* Use Symfony\Security\Guard to manage the Authentication process
* Use League\OAuth2-Client or Opauth or HWIOAuthBundle for external OAuth2 authentication
* Use League\OAuth2-Server or FOSOAuthServerBundle for OAuth2 server for API
* Use Sylius\RBAC or FOSUserBundle for User/Role management

The combination of HWIOAuthBundle / FOSOAuthServerBundle / FOSUserBundle is widely supported and more 'native' to Symfony, but requires the use of the full framework, bundles, Doctrine ORM, and YAML-based config. The alternatives are built as stand-alone interoperable PSR components and will provide greater future flexibility and a gentler migration path, but will require more work to integrate.

Alternatives such as Sentinal which provides all the required features in a single integrated component would require choosing a different component ecosystem, such as Laravel.

Possible packages:
* [https://cartalyst.com/manual/sentinel/2.0 Sentinel] - Full combined package, but requires Laravel ORM, extensions like OAuth are for-pay
* Sylius [http://docs.sylius.org/en/latest/components/Rbac/index.html RBAC]
* PHP League [http://oauth2-client.thephpleague.com/ OAuth2 Client] and [http://oauth2.thephpleague.com/ OAuth2 Server] (PSR7 based)
* https://github.com/knpuniversity/oauth2-client-bundle uses PHP League OAuth2 Client, requires framwork but fork?
* https://github.com/gigablah/silex-oauth uses other OAuth library but crib code?

OAuth2 Servers:
* PHP League [http://oauth2.thephpleague.com/ OAuth2 Server] - PSR7 based
* Friends of Symfony [https://github.com/FriendsOfSymfony/oauth2-php OAuth2 Server] - HTTPFoundation based
* [https://github.com/bshaffer/oauth2-server-php bshaffer OAuth2 server] - Has HTTPFoundation wrapper, example Silex app

Stuff:
* http://benedictroeser.de/2015/12/using-symfony-guard-component-without-the-whole-framework/
* https://github.com/chrootLogin/silex-userprovider/tree/nextgen
* http://www.jasongrimes.org/2014/09/simple-user-management-in-silex/
* http://loige.co/symfony-security-authentication-made-simple

Chosen components:

* User Manager: https://github.com/chrootLogin/silex-userprovider ported to Silex2 and upgraded
* RBAC: [http://docs.sylius.org/en/latest/components/Rbac/index.html Sylius RBAC] with custom Voter
* OAuth2 Client: TBC
* OAuth2 Server: TBC

User Manager modifications needed:
* Silex2 port
* Admin settings
* Add user screen
* Invite emails
* Guard?
* Console add user optional role
* Console enable/disable user

RBAC:
* Service provider
* Voter
* Forms
* User Manager override classes

OAuth:
* ???

Defined Roles:
* System Admin - Admin rights for system install, i.e. config, etc. Not inherited.
* ARK Admin - Admin rights for ARK instance, i.e. users, etc. Inherits Supervisor, User.
* ARK Supervisor - Site supervisor rights, i.e. checking, mod changes, etc.
* ARK User - General user rights, i.e. data entry.
* Anon User

@@ Line 29: / Line 29: @@
 ARK User Levels are a renaming of Symfony Security module Roles to prevent confusion with ARK RBAC Roles:
-* ROLE_SYSADMIN - System Admin - Admin rights for system install, i.e. config, etc.
+* ROLE_SYSADMIN - System Admin - Admin rights for an ARK system install.
-* ROLE_ADMIN - ARK Admin - Admin rights for an ARK website instance.
+* ROLE_ADMIN - ARK Admin - Admin rights for an ARK instance.
-* ROLE_USER - General user rights for any other role within an ARK.
+* ROLE_USER - General user rights for any other role within an ARK instance.
-* ROLE_ANON - Anon User
+* ROLE_ANON - Anonymous users.
 == RBAC Model ==

← Older revision		Revision as of 11:21, 30 December 2016
Line 85:		Line 85:

	Initial implementation will not support Hierarchical RBAC, this will be added later.		Initial implementation will not support Hierarchical RBAC, this will be added later.
		+
		+	* https://github.com/Sylius/Rbac
		+	* https://github.com/zendframework/zend-permissions-rbac
		+	* https://github.com/FriendsOfSymfony/FOSUserBundle
		+
		+	* https://knpuniversity.com/screencast/new-in-symfony3/guard-authentication

← Older revision		Revision as of 21:32, 21 November 2016
Line 83:		Line 83:
	* Roles - A set of Permissions which can be granted to a user		* Roles - A set of Permissions which can be granted to a user
	* Users - An individual who can be assigned Roles but not Permissions		* Users - An individual who can be assigned Roles but not Permissions
		+
		+	Initial implementation will not support Hierarchical RBAC, this will be added later.

@@ Line 82: / Line 82: @@
 * Permissions - Core security entity, check if granted to User to allow an action
 * Roles - A set of Permissions which can be granted to a user
-* Groups - A collection of users
+* Users - An individual who can be assigned Roles but not Permissions

@@ Line 80: / Line 80: @@
 == RBAC Model ==
-* Permissions
+* Permissions - Core security entity, check if granted to User to allow an action
-* Roles
+* Roles - A set of Permissions which can be granted to a user
-* Groups
+* Groups - A collection of users
-* Users
+* Users - An individual account

@@ Line 1: / Line 1: @@
 = Security =
-ARK currently uses PEAR LiveUser for user authentication and authorisation, but this hasn't been updated since 2010. It is a security risk, and also lacks many features like federated login. The ARK API currently uses plain text user and password in the request URL which is insecure. ARK2 will require a new security solution, especially for the API calls from client apps.
+ARK2 uses the Symfony Security component. ARK2 extends this component with its own User Provider and Role-Based Access Control to manage user rights within an ARK.
 * User Authentication
 ** Token-based
 ** Local user database for stand-alone/internal use
-** Via OAuth and OpenID authentication services (Google, Facebook, etc)
+** Distributed Via OAuth and OpenID authentication services (Google, Facebook, etc)
 * User Authorisation
 ** Role-Based Access Control (RBAC) model based on Users/Roles/Permissions
-The combination of HWIOAuthBundle / FOSOAuthServerBundle / FOSUserBundle is widely supported and more 'native' to Symfony, but requires the use of the full framework, bundles, Doctrine ORM, and YAML-based config. The alternatives are built as stand-alone interoperable PSR components and will provide greater future flexibility and a gentler migration path, but will require more work to integrate.
+HTTPS is required and is supported using LetsEncrypt to obtain SSL certificates.
-Alternatives such as Sentinal which provides all the required features in a single integrated component would require choosing a different component ecosystem, such as Laravel.
+=== User Status ===
-Possible packages:
+The User account has the following possible statuses:
-OAuth2 Servers:
+* Registered - The user has registered with the website but not yet verified their email (if required)
-* PHP League [http://oauth2.thephpleague.com/ OAuth2 Server] - PSR7 based
+* Verified - The user has responded to the email verification but not yet been enabled by the admin (if required)
-* Friends of Symfony [https://github.com/FriendsOfSymfony/oauth2-php OAuth2 Server] - HTTPFoundation based
+* Enabled - The user is enabled to use the website
-* [https://github.com/bshaffer/oauth2-server-php bshaffer OAuth2 server] - Has HTTPFoundation wrapper, example Silex app
+* Disabled - The user has been disabled by the admin and cannot login or reset their account
-Stuff:
+=== User Levels ===
-Chosen components:
+ARK User Levels are a renaming of Symfony Security module Roles to prevent confusion with ARK RBAC Roles:
-* User Manager: https://github.com/chrootLogin/silex-userprovider ported to Silex2 and upgraded
+* ROLE_SYSADMIN - System Admin - Admin rights for system install, i.e. config, etc.
-* RBAC: [http://docs.sylius.org/en/latest/components/Rbac/index.html Sylius RBAC] with custom Voter
+* ROLE_ADMIN - ARK Admin - Admin rights for an ARK website instance.
-* OAuth2 Client: TBC
+* ROLE_USER - General user rights for any other role within an ARK.
-* OAuth2 Server: TBC
+* ROLE_ANON - Anon User
 == RBAC Model ==
-* Permissions - Core security entity, check if granted to User to allow an action
+* Permission - A specific right that may be granted to view data or perform an action within the system
-* Roles - A set of Permissions which can be granted to a user
+* Actor - A persistent entity who can view data or perform actions within the system
-* Users - An individual who can be assigned Roles but not Permissions
+* Role - A set of Permissions that can be assigned to an Actor
+* User - A security account for logging into the system that can be linked to one or more Actors

← Older revision		Revision as of 21:24, 20 November 2016
Line 77:		Line 77:
	* ARK User - General user rights, i.e. data entry.		* ARK User - General user rights, i.e. data entry.
	* Anon User		* Anon User
		+
		+	== RBAC Model ==
		+
		+	* Permissions
		+	* Roles
		+	* Groups
		+	* Users