ok, I hadn't considered Shiro as a 'security server' in its own right
like this before. I'd always considered it a library for connecting to
some other security/identity server. I can see how this might work, and
will offer a common api for multiple different realms, but a single
server could quickly become overwhelmed. Is there anything in Shiro that
would make federation or clustering of such a server particularly
problematic?
Thanks
Jason.
Les Hazlewood wrote:
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
