On Thu, Jan 21, 2010 at 1:14 AM, Matthew Ishii <[email protected]> wrote: > 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.
Yep, this is a core strength in Shiro's architecture. > 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. Correct. You have both options - the 'clients' can contact to a central security server or they can act as servers themselves and have their own SecurityManager and set of Realms to communicate with any datasource necessary. The application requirements and system topology will determine the better approach depending on the situation. > I would suggest that these ambiguities be worked out into various 'use cases' > accessible on the index page. That's a good idea! Maybe like a 'recipes' section? Naturally this has taken a back burner since the overall reference documentation is still in progress. If anyone is willing to contribute to the wiki, let me know - > 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. We look forward to it! All contributions are appreciated. > 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. Well it can work in both ways. Like I said before, the most common use case is where Shiro is used both as a server and a 'client' API in the same JVM in a single application (often a web application). This is naturally the best performing option since there are no RPC calls anywhere. But it does well in server-only or client-only scenarios too. For example, there are more than a few Flex applications that I've been involved with that use Shiro remotely by a little indirection: I created a SubjectService that acts as a Flex RemoteObject endpoint and immediately delegates those calls to the Shiro API. That is, the SubjectService implementation just called SecurityUtils.getSubject().XXX - it was a passthrough mechanism. It would be much nicer though to have a Subject ActionScript API that can be used transparently in Flex instead of the Service approximation. At the end of the day, both solutions would work the same way under the hood, but it is a little cleaner to have some native ActionScript code to do this. We just don't have this in our source tree yet (anyone want to help with this? ;)) The most complicated Shiro environment I've seen is one that has many different applications performing federated session management, all using the native SessionManager mechanisms. But it works well. And that's a _whole_ 'nuther story :) Cheers, Les
