You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by Siegfried Goeschl <si...@it20one.at> on 2008/05/08 21:29:47 UTC
[Fwd: [jsecurity-dev] Looking around at JSecurity ....]
FYI
-------- Original Message --------
Subject: [jsecurity-dev] Looking around at JSecurity ....
Date: Thu, 08 May 2008 21:14:24 +0200
From: Siegfried Goeschl <sg...@gmx.at>
Reply-To: dev@jsecurity.codehaus.org
To: dev@jsecurity.codehaus.org, general@incubator.apache.org
Hi folks,
a few thoughts along the line while looking at the project
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
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 ... :)
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?
Cheers,
Siegfried Goeschl
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [Fwd: [jsecurity-dev] Looking around at JSecurity ....]
Posted by Les Hazlewood <le...@hazlewood.com>.
Here's my response for those interested...
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
On Thu, May 8, 2008 at 3:29 PM, Siegfried Goeschl
<si...@it20one.at> wrote:
> FYI
>
>
>
> -------- Original Message --------
> Subject: [jsecurity-dev] Looking around at JSecurity ....
> Date: Thu, 08 May 2008 21:14:24 +0200
> From: Siegfried Goeschl <sg...@gmx.at>
> Reply-To: dev@jsecurity.codehaus.org
> To: dev@jsecurity.codehaus.org, general@incubator.apache.org
>
>
>
> Hi folks,
>
> a few thoughts along the line while looking at the project
>
> 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
>
> 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 ... :)
>
> 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?
>
> Cheers,
>
> Siegfried Goeschl
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org