ARK2/Security

From ARK
Revision as of 21:32, 21 November 2016 by John Layt (talk | contribs) (→‎RBAC Model)

Jump to: navigation, search

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:

OAuth2 Servers:

Stuff:

Chosen components:

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

  • 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
  • Users - An individual who can be assigned Roles but not Permissions

Initial implementation will not support Hierarchical RBAC, this will be added later.

Retrieved from "https://ark.lparchaeology.com/wiki/index.php?title=ARK2/Security&oldid=124434"