Difference between revisions of "ARK2/Security"

From ARK
Jump to: navigation, search
(RBAC Model)
(User Levels)
 
(4 intermediate revisions by the same user not shown)
Line 1: Line 1:
 
= Security =
 
= 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.
  
Requirements
 
 
* User Authentication
 
* User Authentication
 
** Token-based
 
** Token-based
 
** Local user database for stand-alone/internal use
 
** 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
 
* User Authorisation
 
** Role-Based Access Control (RBAC) model based on Users/Roles/Permissions
 
** 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:
+
HTTPS is required and is supported using LetsEncrypt to obtain SSL certificates.
* 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 Status ===
  
* User Manager: https://github.com/chrootLogin/silex-userprovider ported to Silex2 and upgraded
+
The User account has the following possible statuses:
* 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:
+
* Registered - The user has registered with the website but not yet verified their email (if required)
* Silex2 port
+
* Verified - The user has responded to the email verification but not yet been enabled by the admin (if required)
* Admin settings
+
* Enabled - The user is enabled to use the website
* Add user screen
+
* Disabled - The user has been disabled by the admin and cannot login or reset their account
* Invite emails
+
* Locked - The user has failed the password check and must reset their password, or the admin has required them to reset their password
* Guard?
+
* Expired - The expiry date for the account has passed and must be extended by the admin
* Console add user optional role
 
* Console enable/disable user
 
  
RBAC:
+
=== User Levels ===
* Service provider
 
* Voter
 
* Forms
 
* User Manager override classes
 
  
OAuth:
+
ARK User Levels are a renaming of Symfony Security module Roles to prevent confusion with ARK RBAC Roles:
* ???
 
  
Defined Roles:
+
* ROLE_SYSADMIN - System Admin - Admin rights for an ARK system install.
* System Admin - Admin rights for system install, i.e. config, etc. Not inherited.
+
* ROLE_ADMIN - ARK Admin - Admin rights for an ARK instance.
* ARK Admin - Admin rights for ARK instance, i.e. users, etc. Inherits Supervisor, User.
+
* ROLE_USER - General user rights for any other role within an ARK instance.
* ARK Supervisor - Site supervisor rights, i.e. checking, mod changes, etc.
+
* ROLE_ANON - Anonymous users.
* ARK User - General user rights, i.e. data entry.
 
* Anon User
 
  
 
== RBAC Model ==
 
== 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
* Groups - A collection of users
+
* Role - A set of Permissions that can be assigned to an Actor
* Users - An individual account
+
* User - A security account for logging into the system that can be linked to one or more Actors

Latest revision as of 10:11, 9 April 2018

Security

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
    • Distributed Via OAuth and OpenID authentication services (Google, Facebook, etc)


  • User Authorisation
    • Role-Based Access Control (RBAC) model based on Users/Roles/Permissions

HTTPS is required and is supported using LetsEncrypt to obtain SSL certificates.

User Status

The User account has the following possible statuses:

  • Registered - The user has registered with the website but not yet verified their email (if required)
  • Verified - The user has responded to the email verification but not yet been enabled by the admin (if required)
  • Enabled - The user is enabled to use the website
  • Disabled - The user has been disabled by the admin and cannot login or reset their account
  • Locked - The user has failed the password check and must reset their password, or the admin has required them to reset their password
  • Expired - The expiry date for the account has passed and must be extended by the admin

User Levels

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 an ARK system install.
  • ROLE_ADMIN - ARK Admin - Admin rights for an ARK instance.
  • ROLE_USER - General user rights for any other role within an ARK instance.
  • ROLE_ANON - Anonymous users.

RBAC Model

  • Permission - A specific right that may be granted to view data or perform an action within the system
  • Actor - A persistent entity who can view data or perform actions within the system
  • 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