|Date and Author(s)|
We propose defining the following modules with corresponding interfaces, any or all of which may be accessible under this security plan: accounting, user database, usage reports, resource allocation and management, scheduler, queue manager, system monitor, job manager & monitor, node configuration and build manager, data migration.
An incoming request is deemed to be XML if the first two characters are "". If they are "GET," "POST," or anything else, the request is deemed to be https.
If the request is XML, the connection is assumed to be an XML command stream, with the socket open for responses in the other direction. The server will parse each top-level XML element as soon as it is complete (this is a controversial provision).
If the request is HTTP GET or POST to file /XML, the command is expected to be a form submission with one argument of the form xml=data (such as https://server:12345/XML?xml=data). Data is then interpreted as a single SciDAC SSS XML command. The XML response will be returned as a
block in an HTML page.
If the request is HTTP to any other file, the server will implement a small Web site with the following content:
- forms for starting, stopping, and otherwise controlling the server,
- one or more forms to assist a human in producing XML for testing purposes. These forms would have a TEXTAREA filled-in with the XML markup with blanks where parameters should appear.
- Human connects a browser to https://server:12345 and receives an HTML form containing the XML framework already filled-in. The human adds parameters in the appropriate places and hits "submit." They get a HTML page with the returned XML.
- A computer opens an SSL connection and sends a stream of XML commands, receiving a stream of responses back.
- An adminstrator connects a browser to https://server:12345 and accesses a series of Web pages that allow them to review server performance and change parameters.
Addendum: Al Geist Date: Sat Feb 9 15:36:55 2002 (GMT)
I edited the title and first paragraph a little to make this a "proposal" for a security plan rather than appearing like something that had already been voted on. Overall, seems like a reasonable plan for the Scalable Systems Software Suite. Does not impose undue hardship on the the component writers and doesn't preclude the suite being run on clusters with only internal access and no security.
Addendum: Narayan Desai Date: Wed Feb 13 19:04:22 2002 (GMT)
This is fairly similar to what we have been discussing the build/config
group in the context of the security component. So far, we have
been talking about accomodating security inside of the wire protocol.
This would allow the already existing service directory to support
arbitrary security systems without having too much more infrastructure
overhead. This also allows, as Al says above, the cluster
administrator to choose which protocols are employed in the system.
The wire protocols that have been discussed so far are the basic protocol
that Rusty proposed at the last face to face, and in BCM we have been
talking about a challenge response protocol that looks a lot like the
basic protocol with the addition of a challenge/response preamble to communication.
Addendum: Rusty Lusk Date: Thu Feb 14 16:46:21 2002 (GMT)
We were planning to suggest at the meeting a simple extension to the basic wire protocol we adopted at the last meeting to provide authentication when connections are made with the basic protocol. It is the challenge-response authentication described on p 602 of Tanenbaum's "Computer Networks" book. It's main virtue is that it relies only on the existence of Unix crypt, and requires no other libraries or protocols. I would like to propose that we add it to the basic protocol as a basic authentication mechanism. We use this in mpd (C) and have a python implementation as well, for our prototype components in this project. We would like to distribute it as a library to accelerate the actual communication between separate components.