I for one would be *very* interested - I will be going down this path
shortly, and have been watching this thread keenly, and dilligently saving
the posts. A mini how-to or summary would be very helpfull to me.
Andrew
----- Original Message -----
From: "Kenworthy, Edward" <[EMAIL PROTECTED]>
To: "'jBoss'" <[EMAIL PROTECTED]>
Sent: Monday, December 11, 2000 12:05 PM
Subject: RE: [jBoss-User] Security
> Hoody Hoo!
>
> Ok I now have it all working ! I've re-written the ServerLoginModule so
that
> it reads usernames and passwords from one properties file and usernames
and
> roles from another. Which is exactly what I need for client and bean
> development, as I won't have to modify them when I re-implement my
> ServerLoginModule to use the "real" security mechanism. (I still use
> setPublicCredential() to tie roles to Subjects but I think a role should
> really be a Principal - but I'll hold off on that as that would require a
> change to JaasSecurityManager.
>
> Would anyone be interested in my writing up what I did, including every
> useful tid-bit people have posted here plus what I learned doing it ?
>
> Thanks to everyone for your help!
>
> Edward
>
> -----Original Message-----
> From: Oleg Nitz [mailto:[EMAIL PROTECTED]]
> Sent: 08 December 2000 08:36
> To: jBoss
> Subject: Re: [jBoss-User] Security
>
>
> "Kenworthy, Edward" wrote:
> >
> > Ok, I think I understood that. But I'm still not sure where I actually
> setup
> > my users' roles. Or are you saying that for your simple
> JaasSecurityManager
> > you can't define roles ?
> I am saying that with SimpleServerLoginModule you can't, you need to
> write your own
> server LoginModule for that.
>
> > In which case, err <scratches head> how can it work
> > ? After all EJB security depends on roles, whether you kludge it (as
> > SimpleRealmMapping does) or implement it fully.
> I don't want to copy&paste code from SimpleRealmMapping just to provide
> a dummy implementation for role mapping. As I pointed out before, you
> can use SimpleRealmMapping together with SimpleServerLoginModule if you
> want to have role names equal to user names.
> Unlike SimpleRealmMapping, SimpleServerLoginModule is not just an
> example, but it can be used in production without changes (IMHO).
> I think that database representation of role mapping highly varies, so
> it doesn't make sense to implement one universal role mapping
> LoginModule with dozen options and dozen Kb of their description.
> If you don't think so, feel free to contribute such LoginModule.
>
> Regards,
> Oleg
>
> >
> > Hi Edward,
> >
> > Kenworthy, Edward wrote:
> > KE> Normally of course I wouldn't use a user name as the role name. But
I
> > though
> > KE> the simple realm mapper used principal == role.
> > That is true for SimpleRealmMapping but not for
> > SimpleServerLoginModule. The latter doesn't define any roles.
> >
> > KE> Looking at JaasSecurityManager it appears to do everything I would
> > expect.
> > KE> However whilst I can see where _roles is populated
> >
> > KE> _roles.put(principal, subj.getPublicCredentials())
> >
> > KE> I can't really make sense of this.
> >
> > KE> I understood entries _roles to correspond to <role-name> in the
> > deployment
> > KE> descriptor, but it seems to being populated with a key of principal
> (ok
> > KE> thats fine) and subj.getPublicCredentials(). Now I thought a
subject's
> > KE> public credentials were things like public keys. OK I can see you
> might
> > KE> shoe-horn roles in there as well but is that how it's intended ?
(And
> is
> > KE> there and instance of JaasSecurityManager per bean per user ?)
> > I'm an author of this trick, Dan never agreed that this is a good
> > idea, I see that you don't like it, too :-)
> > My idea is: the set of roles for beans is something that is used for
> > authorization, i.e. a kind of Credentials in JAAS terms.
> > Since server JAAS LoginContext (unlike the client one) is used
> > internally by jBoss, I decided not to introduce any special interfaces
> > to distinguish role Credentials from other ones - just because there
> > is no other ones.
> > I decided to keep things simple and store roles as Strings.
> > The number of different JaasSecurityManager instances equals the
> > number of different JNDI names starting with "java:/jaas" in all
> > *jboss.xml files. Normally, this number should equal the number of
> > application entries in the server auth.conf file, but if the requested
> > name is not found there, new instance is created with the requested
> > name, and "other" section of auth.conf is used for that.
> > Each instance of JaasSecurityManager holds the cache for successfully
> > authenticated users and the cache for their roles - a Set of roles for
> > each user. The Set is used for evaluation of isCallerInRole().
> > EJB specification recommends that J2EE application (if I understand
> > correctly, this means the set of beans in one ear file) has one
> > "security view" - the common set of roles used for authorization in
> > all beans of this application. One security view should correspond to
> > one application entry in the server auth.conf file, therefore to one
> > JaasSecurityManager instance.
> >
> > KE> My next puzzle is where do the subject's public credentials get set
?
> > In server LoginModule. SimpleServerLoginModule doesn't do this.
> > If you want just to play with roles, you may specify
> > SimpleRealmMapping in your jboss.xml file as role-mapping-manager.
> > Note, that authentication-module and role-mapping-manager can be set
> > independently: one can work via JAAS, other not, or both can work via
> > JAAS but correspond to different JNDI names and different application
> > entries in auth.conf.
> >
> > Best regards,
> > Oleg
> >
> > --
> > --------------------------------------------------------------
> > To subscribe: [EMAIL PROTECTED]
> > To unsubscribe: [EMAIL PROTECTED]
> > Problems?: [EMAIL PROTECTED]
> >
> > --
> > --------------------------------------------------------------
> > To subscribe: [EMAIL PROTECTED]
> > To unsubscribe: [EMAIL PROTECTED]
> > Problems?: [EMAIL PROTECTED]
>
>
> --
> --------------------------------------------------------------
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> Problems?: [EMAIL PROTECTED]
>
>
> --
> --------------------------------------------------------------
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> Problems?: [EMAIL PROTECTED]
>
>
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
