Alternative security mechanisms for IceGrid registration

[joshmoore]

I'm currently running into a situation where I'd like finer control over which services can register themselves in our grid and what information I have about them after they register. At the moment, I'm looking for suggestions, which might eventually turn into useful RFEs.

All our servers are within a firewall using Glacier2 for session management. The central data server, blitz, contains all the logic for authentication/authorization. Processor servers are started on nodes as a particular blitz user (different from the OS user) and take job requests from blitz.

The issue is how does blitz know that the processor is authorized to take a particular job with the rules: (1) root can run anyone's jobs and (2) anyone else can only run their own jobs.

The first solution is to simply prevent non-root users from connecting. This I could do with SSL or a specialized root-only PermissionsVerifier. I'd prefer to allow non-root users to also start processors to allow integration with existing cluster resources. Managing the SSL certificates for N users becomes difficult, but is doable if that solves the problem.

Another solution I thought of, but do not know how to implement, entails having "trusted" processors start with port numbers < 1024. This works under the assumption that a process started as (OS) root on a known host can be "trusted".

The other possibility I see is to implement this in user code, though management of the multiple processors becomes a bit convoluted.

• User submits job
• blitz gets a list of all processors from registry
• blitz asks all processors to provide login info,
• and manages a map from user->processor
• blitz passes job to any processor for user or root or throws exception.

This solves the issue of blitz not trusting the processor but it leaves the processors potentially at risk of being misused by a malicious blitz (especially if processors eventually register themselves with multiple icegrid registries.)

[matthew]

Before I can try to help, I need to make sure I understand what you are asking

So you have a situation similar to this:
- Users on the grid register their processor with the grid. In addition, there is a set of "root" processors on the grid which can run any job.
- When submitting jobs, users authenticate themselves with the grid (username, password?)
- Users submit jobs for processing (post authentication) The job can be executed by any free root container, or any containers "belonging" to that end user.

Is that more or less correct?

[joshmoore]

Exactly. Thanks for working through the full explanation.

All authentication of users happens via the blitz username/passwords, and I'm currently looking into the authentication/authorization options for the processors.

I think a simplified question covering most of my issues would be:

" Is there a way to query the authentication information for a processor after it has registered itself with the grid via a PermissionsVerifier? "

If yes, then I should be able to solve my problem. If not, I either have to do it in application code, or hope for a more ingenious solution from you.

Best wishes,
~Josh

[joshmoore]

Maybe I should have just said, "That's correct".

[benoit]

Hi Josh,

Sorry for the late answer. Could you detail how the processors are registered with IceGrid? It's not clear to me exactly how this works. Are "processors" IceGrid clients that create administrative sessions with IceGrid to register well-known objects for instance?

Cheers,
Benoit.

[joshmoore]

Originally Posted by benoit

Sorry for the late answer.

No worries.

Could you detail how the processors are registered with IceGrid? It's not clear to me exactly how this works. Are "processors" IceGrid clients that create administrative sessions with IceGrid to register well-known objects for instance?

The processors are currently deployed in a static fashion with the IceGrid application, registering themselves on start-up. But I would like for users to be able to add processors after the fact. Imagine a system with, say, 4 nodes all running root-processors. If a user happens to have access to 25 nodes on another system, I'd like him/her to be able to:

qsub -n 25 omero processor

which would start a processor on all 25 nodes, which would use IceGrid.AdminPrx instances to register themselves. This is within the firewall, so these users are trusted to some extent, but I can't allow them to have access to other users' data.


As ever, thanks for the time.
~Josh.

[benoit]

Hi Josh,

So only the user that added the processors on the 25 nodes should be able to use them, correct? And to enforce this you would like to be able to retrieve the authentification information used by the client that registered the processors with IceGrid::Admin.

We do save the user id of the user that created or updated an IceGrid application. It can be retrieved from the ApplicationInfo structure returned by the IceGrid::Admin::getApplicationInfo method (see slice/IceGrid/Admin.ice). However, there's currently no easily way to lookup an application by object, adapter or server so you wouldn't be able to easily retrieve this information. Also, you would need to create an admin session just to retrieve this information which is probably undesirable.

I think the simpler might be to implement your own processor registry service. New processors are added to this registry and you would also save the necessary authentication information. It would provide a lookup interface to easily lookup processors for a given user. This processor registry could also take care of the registration of the processor servers with IceGrid so that your clients don't have to talk with the registry directly.

Cheers,
Benoit.

[joshmoore]

Thanks for the info, Benoit.

I don't see opening up an administrative session as being a problem since the central blitz server which would be doing that is the most trusted instance in the grid. Taking a look at ApplicationInfo, the problem would probably be more one of concurrency, since there is only one string for updateUser.

I'll begin implementing a handshake then for all processors, but would certainly be open for suggestions on the "processor registry" as you call it. The idea of having the blitz server handle the registration is probably a very good one, perhaps even permitting processors from outside the firewall.

Nevertheless, I think storing the authentication of all components context in the IceGrid registry and being able to query it could prove generally useful, like many of the other numerous RFEs floating around. It might make the "application" feel more like a surrounding distributed container though, as opposed to just a descriptor of components.

In any event, many thanks.

Regards,
~Josh.