Thanks, Pushpalanka. -- Pushpalanka Jayawardhana, B.Sc.Eng.(Hons). Software Engineer, WSO2 Lanka (pvt) Ltd; wso2.com/ Mobile: +94779716248 Blog: pushpalankajaya.blogspot.com/ | LinkedIn: lk.linkedin.com/in/pushpalanka/ | Twitter: @pushpalanka
On Mon, Aug 18, 2014 at 10:40 PM, Dhanuka Ranasinghe <[email protected]> wrote: > > > *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. >>> >> +1 for considering XACML as an option. This will allow us to make the permission model more fine grained. In addition to restricting depending the user role, we can consider other attributes like 'within which time period a user is allowed to access the environment' etc., as well with this approach. The extend-ability will come with the cost of some added complexity though. > >> 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 > >
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
