JSecurity configuration documentation

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

JSecurity configuration documentation

Raif S. Naffah-3
hello there,

* besides the Javadoc in the org.jsecurity.web.servlet.JSecurityFilter, is
there any additional documentation that describes how to configure
JSecurity?  if there is, a URL would be much appreciated.

* are there any plans, or would there be an interest, in providing a
configuration API, based on a W3C Schema and xml-to-Java binding classes,
generated from Apache XMLBeans for example?


cheers;
rsn


signature.asc (232 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: JSecurity configuration documentation

Les Hazlewood-2

* besides the Javadoc in the org.jsecurity.web.servlet.JSecurityFilter, is
there any additional documentation that describes how to configure
JSecurity?  if there is, a URL would be much appreciated.

Hi Raif,

For .ini based configuration, not at the moment.

At least for the purpose of this email, you can consider our text-based approach a rudimentary mechanism for dependency injection.  For example:

beanA = some.fully.qualified.ClassA
beanA.property1 = Hello World

myBean = some.fully.qualified.Class
myBean.propertyA = $beanA

 * are there any plans, or would there be an interest, in providing a
configuration API, based on a W3C Schema and xml-to-Java binding classes,
generated from Apache XMLBeans for example?

There hasn't been any effort to move in that direction.  The configuration above (rudimentary .ini config) seems to be more desireable and agreeable to the majority of users.  A lot of us are kinda "XML'd out" :)  But if there is enough interest in the community for XML-based config, I'm sure we would probably support it.  Its just there hasn't been anyone asking for it...

Best,

Les

P.S.  This is a little off topic but related to your first question.  Please ignore if you have no interest ;)

It has been a desire of mine for a long time to maybe found another open source project, say, "OGDL" that specified an "Object Graph Definition Language" as a companion to OGNL.  It would be the most concise way to configure any DI framework - Spring, Guice, whatever. 

I wanted to have that as the text-based config used in the JSecurityFilter and we could use a library that could parse the text and transform it into an object graph.  The JSecurity SecurityManager is essentially an object graph with the SecurityManager implementation as the root node.

This would be much nicer and easier to read than XML.  For example:

securityManager: some.fully.qualified.ClassName {
    property1:$someRef
    property2:$anotherRef
    property3: "Hello World"
}

I could see Spring configs using this syntax instead of XML.  Maybe a OgdlApplicationContext.  I should write that :)

Reply | Threaded
Open this post in threaded view
|

Re: JSecurity configuration documentation

Raif S. Naffah-3
hello Lez,

thanks for your prompt reply!


On Tue January 6 2009 08:41:41 Les Hazlewood wrote:

> > * besides the Javadoc in the org.jsecurity.web.servlet.JSecurityFilter,
> > is there any additional documentation that describes how to configure
> > JSecurity?  if there is, a URL would be much appreciated.
>
> Hi Raif,
>
> For .ini based configuration, not at the moment.
>
> At least for the purpose of this email, you can consider our text-based
> approach a rudimentary mechanism for dependency injection.  For example:
>
> beanA = some.fully.qualified.ClassA
> beanA.property1 = Hello World
>
> myBean = some.fully.qualified.Class
> myBean.propertyA = $beanA
...so something similar to PropertyUtilsBean in Apache Commons BeanUtils.  i
was hoping for a document that describes the available/possible properties
etc... of what can be configured more so than how it is configured.

is it safe then to assume that the javadoc of the above class describes all
the possible options?


>  * are there any plans, or would there be an interest, in providing a
>
> > configuration API, based on a W3C Schema and xml-to-Java binding
> > classes, generated from Apache XMLBeans for example?
>
> There hasn't been any effort to move in that direction.  The
> configuration above (rudimentary .ini config) seems to be more desireable
> and agreeable to the majority of users.  A lot of us are kinda "XML'd
> out" :)  But if there is enough interest in the community for XML-based
> config, I'm sure we would probably support it.  Its just there hasn't
> been anyone asking for it...
noted.


> Best,
>
> Les
>
> P.S.  This is a little off topic but related to your first question.
> Please ignore if you have no interest ;)
>
> It has been a desire of mine for a long time to maybe found another open
> source project, say, "OGDL" that specified an "Object Graph Definition
> Language" as a companion to OGNL.  It would be the most concise way to
> configure any DI framework - Spring, Guice, whatever.
> ...[edited]
no thanks :-)  i'm more interested in configuration correctness than
mechanisms, and de-coupling the configuration from the other life-cycle
states of the objects/components.  for me a schema based xml offers the best
guarantees hence the question.


cheers;
rsn

signature.asc (232 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: JSecurity configuration documentation

Les Hazlewood-2
On Tue, Jan 6, 2009 at 2:33 AM, Raif S. Naffah <[hidden email]> wrote:

> beanA = some.fully.qualified.ClassA
> beanA.property1 = Hello World
>
> myBean = some.fully.qualified.Class
> myBean.propertyA = $beanA

...so something similar to PropertyUtilsBean in Apache Commons BeanUtils.  '

Exactly.  We use PropertyUtils under the hood, but we have to do more than just what PU provides, for example, object references via '$' and some other minor things.
 
i was hoping for a document that describes the available/possible properties
etc... of what can be configured more so than how it is configured.

Just as with PropertyUtils or Spring, that would be any Class's JavaDoc.  Any setter on any Class serves as the indicator of what can be injected.

is it safe then to assume that the javadoc of the above class describes all
the possible options?

No - the JavaDoc in JSecurityFilter is just an example bean configuration for filter chains and other things.  You could essentially put any class instance declaration and configure its properties like any other bean.  Anything that BeanUtils supports.
 
> It has been a desire of mine for a long time to maybe found another open
> source project, say, "OGDL" that specified an "Object Graph Definition
> Language" as a companion to OGNL.  It would be the most concise way to
> configure any DI framework - Spring, Guice, whatever.
> ...[edited]

no thanks :-)  i'm more interested in configuration correctness than
mechanisms, and de-coupling the configuration from the other life-cycle
states of the objects/components.  for me a schema based xml offers the best
guarantees hence the question.

Understood.  At the moment, pretty much everyone who wants that kind of correctness, i.e. backing by an XML Schema definition, uses Spring or some other XML bean configuration mechanism. 

Currently the JSecurity team defers to those other more robust mechanisms instead of writing our own, since they're all incredibly powerful already - it sounds like quite a bit of work to provide what they do - bean injection, managing lifecycles, circular dependency detection, etc. 

My 'OGDL' idea was one for an alternate light-weight configuration mechanism for people who didn't want XML or schema correctness.  If they want XML, there are a ton of frameworks out there that provide bean configuration via XML, including even, the JDK.

In any event, the JSecurityFilter supports a 'configClassName' init-param.  You can specify any fully-qualified class name implementation of the Configuration interface (http://www.jsecurity.org/api/org/jsecurity/config/Configuration.html).  The JSecurityFilter will use the default no-arg constructor of that class and then immediately acquire the SecurityManager instance. This allows you to configure the SecurityManager however you wish in case one of our default methods might not be suitable for you.

But then, if you'd like to contribute an XML mechanism that works, please start another thread to discuss it.  I'm not sure if that's a road we want to go down, but we're certainly open to your feedback and suggestions.
 
Best regards,

Les