[Dev] Dev Digest, Vol 13, Issue 1
Brett Wooldridge
bwooldridge at alterpoint.com
Mon May 5 21:40:49 CDT 2008
Yeah, I was thinking about the idea of a StubSecurityService or some such. Without objection I'll create one. It seems that if the security infrastructure is really going to be part of ZAP (and I think it should), other ZAP services should be able to depend on it's availability. In the case of the Scheduler, like most systems we'd like to know "who" is running a job. The StubSecurityService (or NullSecurityServer or whatever) can just return something like "system" as the user. We also have a need for transient backend jobs that are scheduled by the system itself, so this seems like a reasonable addition anyway.
-Brett
On 5/6/08 3:31 AM, "Edmund Grossenbacher" <egrossenbacher at alterpoint.com> wrote:
The recent additions to provider.scheduler instigated these changes. It appears to be trying to install a "username" item into the JobDataMap. The checkin comment says something about "pass authentication token into scripts", which sounds like a dubious addition to a core service anyway...
There are at least two use cases that I would like to support:
(1) In our environment we are using the ZAP for backend services. We want to disable security entirely; this is easy now because we can just explude the server.auth plugin, which includes the web filter and the password file authenticator. But if we exclude that, then anyone who expects to be able to use ISecurityManager will fail, since no-one installs that service anymore... Perhaps it is overkill to check for a missing security manager: we could provide our own "dummy" security manager service that just likes everyone it sees...
(2) I have several transient backend jobs that are effectively scheduled by the system itself on startup. There will be no user in such a case, which would cause trouble with the recent Scheduler changes...
-ed
-----Original Message-----
From: dev-bounces at ziptie.org [mailto:dev-bounces at ziptie.org] On Behalf Of dev-request at ziptie.org
Sent: Monday, May 05, 2008 12:00 PM
To: dev at ziptie.org
Subject: Dev Digest, Vol 13, Issue 1
Send Dev mailing list submissions to
dev at ziptie.org
To subscribe or unsubscribe via the World Wide Web, visit
http://mailman.ziptie.org/listinfo/dev
or, via email, send a message with subject or body 'help' to
dev-request at ziptie.org
You can reach the person managing the list at
dev-owner at ziptie.org
When replying, please edit your Subject line so it is more specific than "Re: Contents of Dev digest..."
Today's Topics:
1. Security changes: dev action required (Edmund Grossenbacher)
2. Re: Security changes: dev action required (Brett Wooldridge)
----------------------------------------------------------------------
Message: 1
Date: Mon, 5 May 2008 11:30:14 -0500
From: Edmund Grossenbacher <egrossenbacher at alterpoint.com>
Subject: [Dev] Security changes: dev action required
To: "dev at ziptie.org" <dev at ziptie.org>
Message-ID:
<B48CB61665A101419E226D4D141D540E0303DB4204 at mail-server.inside.eclyptic.com>
Content-Type: text/plain; charset="us-ascii"
I broke the org.ziptie.zap.security bundle into two bundles as follows:
1. org.ziptie.zap.security contains all "generic" security constructs, including the zprincipal, ISecurityService, and the session stuff. It no longer has an activator, and it no longer registers a service (ISecurityService.) 2. org.ziptie.server.auth contains ZipTie-specific security code, including the old SecurityService implementation which uses the baked password file, and ZHttpContext (or whatever) that installs the web filter. This new bundle registers the ISecurityService osgi server that used to be registered by zap.security.
I have added the new bundle to Build/crates/etc. The server appears to come up, so I'm thinking all is well, BUT:
*** I don't have write access to CVSROOT, so I am unable to update the 'ZipTie' alias. ***
Moving forward, it would be most appreciated if future references to the SecurityService actually checked to see if such a service is installed before doing user things with it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ziptie.org/pipermail/dev/attachments/20080505/a995370d/attachment-0001.html
------------------------------
Message: 2
Date: Mon, 5 May 2008 11:37:47 -0500
From: Brett Wooldridge <bwooldridge at alterpoint.com>
Subject: Re: [Dev] Security changes: dev action required
To: ZipTie Development List <dev at ziptie.org>
Message-ID: <C44566EB.105B6%bwooldridge at alterpoint.com>
Content-Type: text/plain; charset="iso-8859-1"
Cool, thanks for the cleanup. Can you clarify that last bit? Was there a specific instance that caused a problem? I'm not sure what code that relies on the security service should or would do if it weren't present.
-Brett
On 5/6/08 1:30 AM, "Edmund Grossenbacher" <egrossenbacher at alterpoint.com> wrote:
I broke the org.ziptie.zap.security bundle into two bundles as follows:
1. org.ziptie.zap.security contains all "generic" security constructs, including the zprincipal, ISecurityService, and the session stuff. It no longer has an activator, and it no longer registers a service (ISecurityService.) 2. org.ziptie.server.auth contains ZipTie-specific security code, including the old SecurityService implementation which uses the baked password file, and ZHttpContext (or whatever) that installs the web filter. This new bundle registers the ISecurityService osgi server that used to be registered by zap.security.
I have added the new bundle to Build/crates/etc. The server appears to come up, so I'm thinking all is well, BUT:
*** I don't have write access to CVSROOT, so I am unable to update the 'ZipTie' alias. ***
Moving forward, it would be most appreciated if future references to the SecurityService actually checked to see if such a service is installed before doing user things with it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ziptie.org/pipermail/dev/attachments/20080505/d1ba578c/attachment-0001.html
------------------------------
_______________________________________________
Dev mailing list
Dev at ziptie.org
http://mailman.ziptie.org/listinfo/dev
End of Dev Digest, Vol 13, Issue 1
**********************************
_______________________________________________
Dev mailing list
Dev at ziptie.org
http://mailman.ziptie.org/listinfo/dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ziptie.org/pipermail/dev/attachments/20080505/9c4e691a/attachment.html
More information about the Dev
mailing list