Community
Participate
Working Groups
We would need to have support for managing access control of the services themselves, which needs some modifications in the client libs. GRIA/ITI should provide us with the modified client libs adding the PolicyManagement interface to the Job/DataServices.
Any news on this, Ken?
I've patched the GRIA libs to provide access control for the Job and Data service. This functionality is now enabled in g-Eclipse. :) Should we also provide access control for other types of GRIA services?
Cool, thanks Ken!! I see that you activated it for a DataService, so now the top level connection will offer access control management :-) Uh... testing it i get an exception, reporting "Unknown action 'getValidRoles'" ========== (...) Caused by: uk.ac.soton.itinnovation.grid.pbac2.pdp.InvalidActionException: Unknown action 'getValidRoles' at org.apache.axis.message.SOAPFaultBuilder.createFault(SOAPFaultBuilder.java:222) (...) ========== what could be wrong there? > Should we also provide access control for other types of GRIA services? Well, it would be nice to have it for the registry service i guess, right?
(In reply to comment #3) > > Should we also provide access control for other types of GRIA services? > > Well, it would be nice to have it for the registry service i guess, right? OK - I can add this to the registry service. In fact, probably we want this feature available for ALL GRIA services. Of course we don't yet use other services via g-Eclipse (e.g. SLA service), but doing this fix now would make it extensible later. What do you think?
(In reply to comment #3) > Cool, thanks Ken!! > I see that you activated it for a DataService, so now the top level connection > will offer access control management :-) Yes! I haven't checked about the Job Service yet. Not sure if/where this would need to be fixed. > Uh... testing it i get an exception, reporting "Unknown action 'getValidRoles'" > ========== > (...) > Caused by: uk.ac.soton.itinnovation.grid.pbac2.pdp.InvalidActionException: > Unknown action 'getValidRoles' > at > org.apache.axis.message.SOAPFaultBuilder.createFault(SOAPFaultBuilder.java:222) > (...) > ========== > what could be wrong there? Well... just because we now have the functionality to manage access to services doesn't mean that the user will actually be authorised to do so. If you think about it, no users by default will be authorised to even check the policy rules, etc. To enable this requires them to be explicitly authorised on the service. At present, this means giving them the "owner" role. Furthermore, the remote managing of access control rules for services is not by default recognised by the services themselves. This requires a change to their PBAC policies. I've been having a play with policies on a service on my local machine, and have successfully got this to work, so we would need to update the policies in a similar way on all the GRIA Job/Data Services used by the project. Do you have access to any of these servers?, as I dont... Perhaps we could try this on one of the services to start with?
> > Well, it would be nice to have it for the registry service i guess, > > right? > > OK - I can add this to the registry service. In fact, probably we want > this feature available for ALL GRIA services. Of course we don't yet use > other services via g-Eclipse (e.g. SLA service), but doing this fix now > would make it extensible later. What do you think? that would be fine for me, i just wanted to make sure if these GRIA library changes might affect compatibility with other Gria version... what about using our new/modified libs with 5.1 or 5.3? > Yes! I haven't checked about the Job Service yet. Not sure if/where this > would need to be fixed. i started to do that but it is not so trivial... (even if i said the contrary at some point) ... with the current architecture we have to go through the JobID and that is not nice... > > Uh... testing it i get an exception, reporting "Unknown action > > 'getValidRoles'" ========== ... > Well... just because we now have the functionality to manage access to > services doesn't mean that the user will actually be authorised to do > so. > > If you think about it, no users by default will be authorised to even > check the policy rules, etc. To enable this requires them to be > explicitly authorised on the service. At present, this means giving them > the "owner" role. ok you are of course right but the message confused me because it says "Unknown action" as if the method call was not supported. Nothing about "not authorised" > Furthermore, the remote managing of access control rules for services is > not by default recognised by the services themselves. This requires a > change to their PBAC policies. Ah! so this is the reason.... so we need to catch those errors and report them to the user correctly... currently if you try to run "manage permissions" on the connection you get a problemDialog . But from there no way to conclude where the problem is. I thought all GRIA services would support managing their permissions out of the box... Does the GRIA client allow this functionality? > I've been having a play with policies on > a service on my local machine, and have successfully got this to work, > so we would need to update the policies in a similar way on all the GRIA > Job/Data Services used by the project. > > Do you have access to any of these servers?, as I dont... Yes, i have access to iwr-geclipse.fzk.de What has to be done?
(In reply to comment #6) > > > Well, it would be nice to have it for the registry service i guess, > > > right? > > > > OK - I can add this to the registry service. In fact, probably we want > > this feature available for ALL GRIA services. Of course we don't yet use > > other services via g-Eclipse (e.g. SLA service), but doing this fix now > > would make it extensible later. What do you think? > > that would be fine for me, i just wanted to make sure if these GRIA library > changes might affect compatibility with other Gria version... what about using > our new/modified libs with 5.1 or 5.3? The situation is this... I have (so far) added support for managing access for the GRIA Job and Data services. This involves extending the JobService and DataService interfaces to extend PolicyManagement. These changes go into the new jars gria-job-common-5.2-g-eclipse.jar and gria-data-common-5.2-g-eclipse.jar respectively (replacing the original 5.2 jars). Due to a quirk in the way that the services have been implemented, this client fix turns out to be enough to be able to manage certain existing services WITHOUT any modifications to their code. These services include: - Job - Data - SLA - Trade Account It makes no difference if any of these services are GRIA 5.1, 5.2 or 5.3. The only changes required on these services to make them manageable is to update their policies (see below). The following GRIA services were developed more recently, and would not work in their current state, without upgrading to (say) 5.3.1: - Membership - Registry However, the plan is to include this support for managing services in the next release of GRIA (5.3.1 I think). These would also include updated policies to support this. Hope that's clearer! > > Yes! I haven't checked about the Job Service yet. Not sure if/where this > > would need to be fixed. > > i started to do that but it is not so trivial... (even if i said the contrary > at some point) ... with the current architecture we have to go through the > JobID and that is not nice... I can't see why the different services have different implementations of access control support. Perhaps you could direct me to the problem code, for info. > > > Uh... testing it i get an exception, reporting "Unknown action > > > 'getValidRoles'" ========== > ... > > Well... just because we now have the functionality to manage access to > > services doesn't mean that the user will actually be authorised to do > > so. > > > > If you think about it, no users by default will be authorised to even > > check the policy rules, etc. To enable this requires them to be > > explicitly authorised on the service. At present, this means giving them > > the "owner" role. > > ok you are of course right but the message confused me because it says "Unknown > action" as if the method call was not supported. Nothing about "not authorised" I assume that you had updated your code, since I've made a few changes today. What exactly did you try and do? Just select "Manage access" from the context menu? Was this on a data service? Which one? Could you send me the exception too? I might be able to improve the error handling to make a more meaningful suggestion, etc. > > Furthermore, the remote managing of access control rules for services is > > not by default recognised by the services themselves. This requires a > > change to their PBAC policies. > > Ah! so this is the reason.... so we need to catch those errors and report them > to the user correctly... currently if you try to run "manage permissions" on > the connection you get a problemDialog . But from there no way to conclude > where the problem is. > > I thought all GRIA services would support managing their permissions out of the > box... They do, of course, via the admin interface, but not currently via SOAP operations, except on the services mentioned earlier. > Does the GRIA client allow this functionality? No, but it soon will! > > I've been having a play with policies on > > a service on my local machine, and have successfully got this to work, > > so we would need to update the policies in a similar way on all the GRIA > > Job/Data Services used by the project. > > > > Do you have access to any of these servers?, as I dont... > > Yes, i have access to iwr-geclipse.fzk.de > What has to be done? I'll come back to that. I need to be sure about the necessary fixes to the policy, so that we don't have to do this too many times. :)
Created attachment 114812 [details] Exception thrown when trying to "manage permissions" on the GRIA connection
> It makes no difference if any of these services are GRIA 5.1, 5.2 or > 5.3. The only changes required on these services to make them manageable > is to update their policies (see below). thanks for the clarification! > The following GRIA services were developed more recently, and would not > work in their current state, without upgrading to (say) 5.3.1: > > - Membership > - Registry > > However, the plan is to include this support for managing services in > the next release of GRIA (5.3.1 I think). These would also include > updated policies to support this. > > Hope that's clearer! great. Yes. But then we don't worry ATM about these ones, because actually the Job and Data services are the most useful ones to manage > > i started to do that but it is not so trivial... (even if i said the > > contrary at some point) ... with the current architecture we have to > > go through the JobID and that is not nice... > > I can't see why the different services have different implementations of > access control support. Perhaps you could direct me to the problem code, > for info. no, it is not the implementation of AC support which is different, but when you "right click" on the grid project tree elements you end up on objects of different classes, of course, one is a GEclipseFileStore for data objects or on a GridJob, both are MW independent. And from it you need to get to the underlying MW-specific object and decide which one will implement the IProtectable interface. That is the only place where there are some differences. And GridJobs don't have a MW-implementation but GridJobIDs do... well, not very nice that... I implemented it already, but have to do some debugging because a quick try didn't work yet (not committed yet of course) > > ok you are of course right but the message confused me because it says > > "Unknown action" as if the method call was not supported. Nothing > > about "not authorised" > > I assume that you had updated your code, since I've made a few changes > today. What exactly did you try and do? Just select "Manage access" from > the context menu? Was this on a data service? Which one? yes, updated and got your changes, and yes, "Manage access" from the context menu on the GRIA connection mountpoint folder. > Could you send me the exception too? I might be able to improve the > error handling to make a more meaningful suggestion, etc. attached > > I thought all GRIA services would support managing their permissions > > out of the box... > > They do, of course, via the admin interface, but not currently via SOAP > operations, except on the services mentioned earlier. i mean without having to fiddle with the policies admin-side ;-) > I'll come back to that. I need to be sure about the necessary fixes to > the policy, so that we don't have to do this too many times. :) great thanks
