incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Les Hazlewood" <>
Subject Re: [jsecurity-dev] Looking around at JSecurity ....
Date Thu, 08 May 2008 19:36:07 GMT
Hi  Siegfried,

Please see my inline comments...

>  1) would it be possible to integrate non-Java application for SSO, e.g.
> using agents communicating to a central server or is this not the scope of
> the project (i.e. Java only) - might be a stupid question but I miss the big
> picture here

That is absolutely an aim of JSecurity - to allow heterogeneous access
mechanisms.  In essence, this only depends on the remoting
technologies used.  There are production applications today that use
Adobe Flash performing security checks by communicating to a back end
with JSecurity installed.  They communicate with the server via JSON
over HTTP and the server responds in JSON format (there are frameworks
that do the data translation via reflection - we don't worry about

It would be rather easy to do the same for C# for example by using

JSecurity's simple SSO support basically relies on its enterprise
session management.  In every SSO application, a token must be shared
among the trusted entities that allow them to access the same data.
Our token just happens to be the sessionId.  It works like this:

1.  The remote client sends the sessionId with every communication
request to a server that has JSecurity enabled.
2.  The session id is obtained, and a Subject instance is created
based on the user/principal information stored in the corresponding
3.  That Subject is then available during the thread execution in the server.
4.  Security checks occur as normal (using the normal JSecurity API)
inside the server as if it was a local/in-process invocation

The framework we _don't_ have in place today is the nice remoting
proxy implementations for respective frameworks.  Most of us use
Spring, so we use Spring's remoting/proxy support to create remote
representations of a SecurityManager and Subjects that the remote
clients use (as if they were local).  These remoting proxies then
communicate with a JSecurity-enabled server as described in the steps

It is my desire to see us offer some out-of-the-box framework to do
this remoting proxy stuff for end users.  Spring just makes this so
darn easy that we haven't spent much time incorporating into our own

>  2) you expose strong cryptography based on Blowfish - please note that in
> Apache land this requires an ECCN code (for the brave and fearless see
> - you might consider exposing weak
> cryptography (up to 56 bit) to avoid the legal work ... :)

Good thing to know, thanks :)  I think I will want to go down the path
of filling out the paper work though.  The idea is that JSecurity is
supposed to provide all of this stuff for its users if we can.  That
is, a common theme in our framework is that 'we do the hard work so
you don't have to'.  So, although not fun, I think I'll have to go
through it anyway since Cryptography is one of the 4 cornerstones of
the framework.

Thanks for the notification though - I wouldn't have thought of this
if it weren't for your suggestion!

>  3) You are using retroweaver to support JDK 1.4 - are there two
> deliverables (one for 1.4 and 1.5) or only the backported one?

The "ant release" target creates a single .zip release file for
end-users to download.  That target internally generates jsecurity.jar
for 1.5 and above environments as well as jsecurity-1.4.jar and
jsecurity-1.3.jar for backwards compatibility in case people need to
use them.



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message