Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Target Management » Extending dstore server launcher?(To authenticate client at other than the server)
Extending dstore server launcher? [message #653949] Sat, 12 February 2011 02:04 Go to next message
No real name is currently offline 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 Go to previous message
David McKnight is currently offline 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.
>
>
Previous Topic:Pending Changes
Next Topic:rse links not refreshed properly
Goto Forum:
  


Current Time: Sat Oct 25 14:54:46 GMT 2014

Powered by FUDForum. Page generated in 0.02142 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software