Difference between revisions of "ARK2/Security"

From ARK
Jump to: navigation, search
(→‎RBAC Model)
(→‎User Levels)
 
(One intermediate revision 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.
+
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:
−
* [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:
+
* 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
 +
* 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
  
−
Stuff:
+
=== User Levels ===
−
* 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:
+
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 an ARK system install.
−
* 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 instance.
−
* OAuth2 Client: TBC
+
* ROLE_USER - General user rights for any other role within an ARK instance.
−
* OAuth2 Server: TBC
+
* ROLE_ANON - Anonymous users.
−
 
 
−
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
 
  
 
== 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
−
* 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
−
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
 

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
Retrieved from "https://ark.lparchaeology.com/wiki/index.php?title=ARK2/Security&oldid=124912"