You mention that multiple applications could communicate back to a central server via a single unified API. However I was asking about a scenario where these clients were calling into the server for authentication via different protocols, LDAP / Active Directory / etc.
I should explain my situation. Our company has 3 major applications, a back-office CRM written in Java, an image 'processing' application written in PHP/Javascript/AJAX, and a reporting server (jasper-reports). The idea, at the bare minimum, is to create a single sign on capable of retaining user preferences whereby the user logs in only once and will have access to all of our applications. Yet, I read about Shiro and realize I have an opportunity to do much more than this. I could potentially replace the entire security framework. I could create a central authentication/authorization server that would manage the single sign on and security for all three applications. However, because our applications are sold to various customers who will want, by contract, different things. Some of our customers have been listening to consultants who think that X this or Y that is the best, latest, smartest thing. One of our potential contracts right now stipulates that the authentication shall be handled via LDAP. Overkill, in my estimation, but nonetheless ... there it is. So given that situation, would I simply need to code a realm to "plug-in" to the security server in order to handle an LDAP client authentication scheme, or lets say, another customer who wanted Active Directory, I say, 'no problem' whip out a new realm and we are all set. Of course keeping in mind that with each of these scenarios I would be required to write the appropriate client code (using shiro?) as well. I would suggest that these ambiguities be worked out into various 'use cases' accessible on the index page. I am interested in this project on more than a simple business level, as I look at what is possible I am very, very excited about this and will definitely consider contributing from my personal project. I ask all these questions because as someone has mentioned in another response, he has only conceived of Shiro being used in a 'client' type approach which is exactly *opposite* the way I had thought it was intended to be used. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Les Hazlewood Sent: Wednesday, January 20, 2010 6:10 PM To: [email protected] Subject: Re: How Shiro handles different Authentication Protocols 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 >
