I've been working with Larry on a AAA (Authentication/Authorization/Auditing) framework for cornerstone. One of the things that we're discussing is if we should have support for multiple Realms
+1
> I have two questions about this, I guess:
1) Does this sound like a feature people would be interested in? If there isn't a lot of need for it we'll put it on the back burner and maybe write an implementation later that will support it.
I have needed it a couple of times in the past but worked around not having it ;) A fairly common example may be a mail server such as James. In many cases you will want to be able to deliver mail to local users so you would have a Realm such as UnixRealm or NTRealm etc. But you may want to also host simple mail accounts that don't have logins on the box so you will have another text/ldap/db realm.
So you would first check the Unix realm and if you could not find anything there you would check the Ldap realm or whatever.
2) We're deciding that (at least within phoenix) Realms will be configured and provided to the Authenticator as blocks. So, if we decide to support multiple realms how do we provide multiple components that implement the same role (in this case Realm) to a Serviceable component? Or would that not be the right interface to implement? What, other than Serviceable, should it become to accomplish this?
Hmm - theres actually no easy way to do this atm. In the past we suggested you create a RealmManager that the Authenticator would use to look up N different Realms.
However I am currently messing around with phoenix down in that area so I will look at trying to fix it so that you can have multiple elements for the same Realm. For the moment just assume it will be possible but test with one realm and I will try to get around to fixing it ;)
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
