From IMarine Wiki
Time: Thursday April 04, 2013, 16:00 - 17:45 Europe/Rome
- Policy Definition Portlet
CNR: Leonardo Candela, Pasquale Pagano;
CERN: Andrea Manzi;
E-IIS: Ciro Formisano, Antonio Savini;
Main Discussions and Actions
The discussion started with AuthN and the fact that we should have a profile in LDAP for each entity that is registered on the infra ( also services). According to Ciro this can be done automatically at GHN startup.
Since this point is crucial, we should continue the discussion by mail.
Policies, which kind of policies we can define?
stateless policies based also on the time, but we cannot define other kind of policies ( for instance disk size etc etc).policies which involves state are considered Service Level Agreement enforcement and could be defined in combination with accounting.( to be discussed later when accounting will be available)
What about the policies on the data? ( access on data collections?). The only way to have policies on access to data is to defined policies regulating the services that are used as mediator to access data.
Policy Management portlet:
- LDAP for the users
- Leo Comment: according to my understanding this is not needed. In defining policies or roles it is not requested to know who are the users. Users should be associated with policies via Roles;
- IS for the services ( to be checked)
- The WSDLs that the services expose should be parsed by the portlet in order to understand the methods to add to the policy (multi-selection of methods should be also implemented)
- Where roles are stored?
- Roles can be stored in Liferay and should be synchronized towards LDAP.
can we align the management of the policies to access a portlet and the access operation to services?
We might have a portlet to configure both, in order to uniform the management? Liferay should also allow to check the roles and the AuthZ by bypassing the core using an "Extension environment", to be discussed by ENG. The current version of UserService and the Policy Management REST API which will be provided by ENG, will allow to get and read policies: this feature could be used to limit the visibility of the portlets according to SOA3 policies. ENG will provide support on REST API.
Leonardo proposed to define policies not linked to roles (as it is now). but we cannot store the policy without a role in SOA3.
- The proposal is to decouple the phase of policy definition (where policy is an allow/deny operation specification only) from role association;
- A possible way to store policy only might be to use a "fake" role;
We can have a simple wizard to start creating a policy and then assign the policy to more then one role.
- Antonio to contact Massimiliano and Andrea to have support on IS and portlets technology;
- ENG to open/update tickets related to the discussed activities;