| Extending dstore server launcher? [message #653949] |
Sat, 12 February 2011 02:04  |
 No real name
Messages: 1
Registered: February 2011 |
Junior Member |
|
|
I'm in a shop that uses Opsware to maintain hundreds of servers, and Opsware uses a common server to regulate the population of users that can use common system accounts to maintain the servers it controls. First, one must login to the common server, known as a "jumpbox", using one's own userid and password. From that common server or jumpbox, you subsequently log into the various servers under Opsware control, using a common service account that is shared amoung various individuals. It's like sudo for access to surogate accounts, except that authenticatoin is between servers instead of processes on a given box.
I'm interested in discussing the possibility of extending the dstore server launcher to provide an authorization mechanism that would authenticate a client against a third entity for when a surogate account (such as our common system accounts) are used. This third entity could be local to the dstore server and provide the same type of functionality as "sudo" does, or it could be remote to the dstore server and authenticate using a server which would implement an interface for granting access to surogate credentials. In my case, this authentication server would implement the interface using Opsware as the authorization authority.
If a particular member of the team changes roles otherwise should no longer have access to these common accounts, without a common point of control, the only way to exclude them would be to change the password for the common account and share that only with the members of the team the require the access. I like the productivity that RSE gives me, but to use it as it is now violates the intention of controlling these common accounts in a central location, such as the Opsware jumpbox. To use RSE "as is" likely would be frowned upon.
|
|
|
| Re: Extending dstore server launcher? [message #654423 is a reply to message #653949] |
Tue, 15 February 2011 17:16  |
David McKnight
Messages: 244
Registered: July 2009 |
Senior Member |
|
|
Regarding the use of RSE, it should be noted that the dstore framework is
but one way that RSE can be used to communicate with servers. RSE is
designed to be protocol-agnostic so you can select from existing services
(ones provided out of the box including dstore, SSH and FTP) or define your
own if that makes sense for your scenarios.
If extending dstore makes the most sence for you then you're free to provide
whatever custom solution you want. There are products that provide a custom
connector service (by extending DStoreConnectService) and their own server
launcher on the host. I'm assuming that's what you have in mind here - let
me know whether that makes sense or not.
<dburrow1690@gmail.com> wrote in message
news:ij4pg2$vsj$1@news.eclipse.org...
> I'm in a shop that uses Opsware to maintain hundreds of servers, and
> Opsware uses a common server to regulate the population of users that can
> use common system accounts to maintain the servers it controls. First, one
> must login to the common server, known as a "jumpbox", using one's own
> userid and password. From that common server or jumpbox, you subsequently
> log into the various servers under Opsware control, using a common service
> account that is shared amoung various individuals. It's like sudo for
> access to surogate accounts, except that authenticatoin is between servers
> instead of processes on a given box.
> I'm interested in discussing the possibility of extending the dstore
> server launcher to provide an authorization mechanism that would
> authenticate a client against a third entity for when a surogate account
> (such as our common system accounts) are used. This third entity could be
> local to the dstore server and provide the same type of functionality as
> "sudo" does, or it could be remote to the dstore server and authenticate
> using a server which would implement an interface for granting access to
> surogate credentials. In my case, this authentication server would
> implement the interface using Opsware as the authorization authority.
> If a particular member of the team changes roles otherwise should no
> longer have access to these common accounts, without a common point of
> control, the only way to exclude them would be to change the password for
> the common account and share that only with the members of the team the
> require the access. I like the productivity that RSE gives me, but to use
> it as it is now violates the intention of controlling these common
> accounts in a central location, such as the Opsware jumpbox. To use RSE
> "as is" likely would be frowned upon.
>
>
|
|
|
Powered by
FUDForum. Page generated in 0.02918 seconds
] 
Search
Help
Register
Login
Home
