incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alan D. Cabrera" <l...@toolazydogs.com>
Subject Re: [jsecurity-dev] Looking around at JSecurity ....
Date Fri, 09 May 2008 16:44:48 GMT
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: 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


Mime
View raw message