+1 for providing the capability. Are we going to define permissions per environment or are there going to be static set of environments? There is a similar mail for Cassandra in [Architecture] Supporting multiple environments for Cassandra.
IMO permissions you have mentioned are too high level for this. It's more practical to associate permissions with a specific database. So having only 'Read' permission (for example) would not allow this. Then if you consider a particular database, real deployment scenarios would want to control who can perform CRUD on that database. So I feel XACML type of an approach is far more practical and extensible here. On Tue, Aug 12, 2014 at 11:06 AM, Dhanuka Ranasinghe <[email protected]> wrote: > Since SS 1.1.0 we do support concepts of environments. There can be > multiple database server instances in single environment. So according to > above use case, there can be multiple database server instances (R&D and > maintenance ) for Development environment. At the moment any user can > access any environment, configured in SS, but we need to control who and > how they gonna access these environment. that is the whole purpose of RBAC. > > So far we have identified four permissions. > > 1. Access (Read) > 2. Create > 3. Modify > 4. Delete > > These permissions should be assigned to user Roles against environments. > By doing that we can check whether particular user has permission to access > the environment. > > Cheers, > Dhanuka > > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- /sumedha m: +94 773017743 b : bit.ly/sumedha
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
