Hi Matt, Yep, you're exactly right - you've described a high-level overview of a more 'enterprisey' security topology that can be supported by Shiro - multiple applications (based on PHP/Ruby/Java/Groovy/whatever) can all communicate back to a central server via a single unified API and the the server, via Realms, can communicate over different protocols to different back-end data sources. The reasoning is that it is better managed and more efficient to have all of the aggregation in that central mechanism than duplicate that effort across all applications and/or languages.
The large majority of Shiro usages are the single app, single JVM scenario, but supporting enterprise topologies has always been a consideration since the project's inception over 5 years ago. In fact, the project originated in a security environment supporting a very large network topology even much more complex than the above example. HTH, Les On Wed, Jan 20, 2010 at 8:38 PM, Matthew Ishii <[email protected]> wrote: > Just a quick question to verify that my understanding of this project > is correct, if you all don’t mind :) > > As I understand it, Shiro is designed in the following way, lets say > we had 3 client connections – a PHP client, Perl client, and java > client. The PHP is connecting via LDAP protocol, perl is connecting > with Active Directory, and java is connecting with plain defaults, > regular jdbc connection with encryption, etc. The PHP/LDAP client > would need to have an interface built for it and so would the PERL/AD > client. They could connect to the ‘security server’ to its ‘security > manager’ via some method, be it SOAP / RPC etc. or if connecting > locally, some other method. Once they connect their subjects could > authenticate/authorize through custom pluggable ‘realms’ subclassed > and designed specifically for their protocol. As for the Java client, > be it connecting over a network or locally, the default security > manager / realm would handle the authentication and authorization for > its subject. > > Does that sound right? I am sorry if I overcomplicated my example – > please say so if I was a little too ambiguous. > > Thank you for your time explaining this. This is definitely something > we will seriously consider using. I am already thinking I will use it > for a personal project if I ever have the time to do one ;0) > > Matt >
