*Dhanuka Ranasinghe* Senior Software Engineer WSO2 Inc. ; http://wso2.com lean . enterprise . middleware
phone : +94 715381915 On Sat, Aug 16, 2014 at 4:32 AM, Manfred Herrmann < [email protected]> wrote: > +1 ... for providing this capability > > my comments inline: > > > 2014-08-15 8:15 GMT+02:00 Sumedha Rubasinghe <[email protected]>: > > +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. >> > > This mail should be answered http://markmail.org/message/4bnghbxw6egknfrn > ... > A consistent usecase/architecture regarding environments is prefered. > > Currently only support static set of environments, but with SS 1.5.0 we > gonna support user define environments and instances. > >> >> 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. >> >> Sorry about high level description. Yes, permission is associate with databases. For example permission = database (db1) + Action (create), but again database is located in an instance and that instance located in an Environment. We thought first go ahead with a simple solution and then we can improve it iterativelly. > Then if you consider a particular database, real deployment scenarios >> would want to control who can perform CRUD on that database. >> > This is already supported in existing SS. It control when provisioning a database to a particular user with privilege template. > So I feel XACML type of an approach is far more practical and extensible >> here. >> > > Is this environment-architecture only for access rss meta-data (like > users/user-rights/templates...)? > Yes partly correct, this solution only apply when users working with SS, and this not apply when users access external databases through JDBC driver. > Or is it for all DB-data like access-rights (CRUD...) on/in a specific RSS > provisioned DB? > > >> >> 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 >> >> > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > >
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
