All good ideas!
However, Les and Siegfried, let's move this discussion to the
jSecurity dev list. This is a general incubation mailing list.
Regards,
Alan
On May 8, 2008, at 12:36 PM, Les Hazlewood wrote:
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
that).
It would be rather easy to do the same for C# for example by using
SOAP or REST over HTTP.
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
session.
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
above.
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
framework.
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
http://www.apache.org/dev/crypto.html) - 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.
Regards,
Les
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
