shiro-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Eacott <ja...@hardlight.com.au>
Subject Re: How Shiro handles different Authentication Protocols
Date Thu, 21 Jan 2010 02:31:59 GMT
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 <matthewrishii@gmail.com> 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
>>
> 

Mime
View raw message