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]
