Hi,
*Overview*
- The Enterprise Store (ES) is a generic store in the same vein as the
Google Play Store
- It allows users to manage and publish assets to a store front
- The ES consists of three applications:Store,Publisher and Social
- This mail deals with the Store and Publisher applications
- The Store app acts as the store front
- The Publisher app provides an interface for users to create , manage
and publish assets to the Store
- The next release of the GREG will include the Enterprise Store.This
will allow asset instances to be created using the Publisher rather than
the Carbon Console.
*Problem*
- The current permission model is tied in with a hard coded storage path
for assets.
- This means that all assets that are managed by the ES need to be
located in a specific storage
path:/{type}/@{overview_provider}/@{overview_name}/@{overview_version}.E.g.
/gadgets/@{overview_provider}/@{overview_name}/@{overview_version}
- However, the GREG has several RXTs that have varying storage paths and
cannot follow a storage path structure as defined above (E.g. service RXT
type which has the storage path as /trunk/services/@{namespace}/@{name})
- In such cases the ES permission model becomes moot
*ES Requirements*
- The ES has several requirements that are needed from any proposed
permission model
- Assume the presence of two users: User1 and User2
- *[ES-R1]* Assets that are created by User1 should not be visible to
User2.The only situation where an asset is visible to users other than the
creator (User1) would be if:
- User2 is a reviewer and the asset is in the In-review state (or
equivalent state as defined by the attached life-cycle)
- User2 is an administrator
- *[ES-R2] *Any user that can log into the Publisher must be able to
create/edit assets and be able to manage the life-cycle actions.
*Existing Permission Model*
- The current permission model involves partitioning collections based
on a provider name (the user that creates an asset)
- When a user logs into the Publisher for the very first time: he/she is
assigned a role such as Internal/private_{user} (created by the ES)
- This role is given read, write , delete and authorize permissions for
a collection created with the name of the user for each asset type managed
by the ES.
- *Example: *The storage path for gadgets is
/gadgets/@{overview_provider}/@{overview_name}/@{overview_version}
- For User1 ,the following collection will be created: /gadgets/user1
- All gadget instances created by User1 would be created under this
collection
- This model allows
- More details of this model can be found in mail threads which were
sent out last year [1][2]
*Main Issues *
- In the GREG model the storage path can be specified to be any path
- The GREG model mandates that the users must have a role that has read,
write and authorize permissions to a collection before they can create
assets.
- *Example: * User1 needs to create a service asset type instance in
the /_system/governance/trunk/services collection
- In order for User1 to be able to create an asset instance he/she
must have a role that has read, write and authorize permissions to that
collection
- *Note:* The visibility of the asset creation UI is handled by a
different set of permissions
- This approach prevents requirements ES-R1 and ES-R2 from been
satisfied
- It is not possible to have isolated user spaces as permissions
applied to a collection are inherited by resources and
collections within it
*Open Questions*
- How can we honour ES-R1 if the concept of a provider is removed and
the storage path is dynamic?
- *Proposed Solution:*
- A single role will be given read,write,delete and authorize
permissions to the root of a storage path (omitting dynamic
values).This
will be provided as an extension point for each asset type.
- The permissions will change based on the rules defined in the
life-cycle
- The visibility will be entirely governed by the life-cycle
definition
- This will be done by removing read permissions from roles based
on the current state of the asset (Currently there is
filtering logic in
the Publisher as read permissions cannot be removed from the
internal/everyone role)
- Should a user that logs into the Publisher be able to perform CRUD
operations on asset types without receiving permission to do so?
- Do we need to mimic the behaviour in the Carbon Console where by a
user must have a set of permissions to even view the asset creation page?
- The current GREG model allows admins to control permissions on a
per asset type basis.E.g. It is possible for User1 to have create rights
for Service asset type but not Gadgets
- This is at odds with ES-R2 requirement given above, where by a user
who logs into the Publisher can create any asset type instance
*Other Concerns*
- There have been suggestions that the permission model should change
from individual ownership to group ownership
- The original model of a single owner for a given asset tallied in with
the way other marketplaces work
- This caters to developers that publish content on their own
*References*
[1] [Architecture] The travelling Asset permission
[2] [Architecture] Meeting notes of regarding Traveling Asset permission
Thank You,
Sameera
--
Sameera Medagammaddegedara
Software Engineer
Contact:
Email: [email protected]
Mobile: + 94 077 255 3005
_______________________________________________
Dev mailing list
[email protected]
http://wso2.org/cgi-bin/mailman/listinfo/dev
