"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]
