OK, hopefully the home stretch.
I've now got it failing which is great, as it shows some authentication is
going on :). However I wasn't expecting it to which is bad :(.
OK so everything is as I described it before (basic JAAS security setup as
previously described.)
I've now added security to my beans, in ejb-jar.xml I have:
<assembly-descriptor>
<container-transaction>
<method>
<ejb-name>CDBean</ejb-name>
<method-name>*</method-name>
</method>
<trans-attribute>Required</trans-attribute>
</container-transaction>
<security-role>
<role-name>EdwardKenworthy</role-name>
</security-role>
<method-permission>
<role-name>EdwardKenworthy</role-name>
<method>
<ejb-name>CDCollectionBean</ejb-name>
<method-name>*</method-name>
</method>
</method-permission>
<method-permission>
<role-name>EdwardKenworthy</role-name>
<method>
<ejb-name>CDBean</ejb-name>
<method-name>*</method-name>
</method>
</method-permission>
</assembly-descriptor>
Normally of course I wouldn't use a user name as the role name. But I though
the simple realm mapper used principal == role.
Anyway, I did this. Logged in as "EdwardKenworthy" pw "EdwardKenworthy" (the
comment in JaasSecurityManager says it uses username == password to
authenticate).
However I get an illegal access exception why I try to lookup
CDCollectionHome.
So I took Toby's advice and used the source.
Looking at JaasSecurityManager it appears to do everything I would expect.
However whilst I can see where _roles is populated
_roles.put(principal, subj.getPublicCredentials())
I can't really make sense of this.
I understood entries _roles to correspond to <role-name> in the deployment
descriptor, but it seems to being populated with a key of principal (ok
thats fine) and subj.getPublicCredentials(). Now I thought a subject's
public credentials were things like public keys. OK I can see you might
shoe-horn roles in there as well but is that how it's intended ? (And is
there and instance of JaasSecurityManager per bean per user ?)
My next puzzle is where do the subject's public credentials get set ?
Looking at ClientLoginModule the only credential I can see being set is
SecurityAssociation.setCredential(password);
But that's not a role and it's not being set on the subject anyway.
I would have been surprised to see it on the client (it's surely information
that belongs on the server) so I had another rummage and found
SimpleRealmMapping, which simply maps principal name to realm (which is what
I thought would happen). However two things make me think that
SimpleRealmMapping isn't being used 1) my code doesn't work <ahem> and 2) I
can find no reference to it in JaasSecurityManager as it implements
RealmMapping directly.
So where do the subject's public credentials get set ?
Help ?
Edward
-----Original Message-----
From: Kenworthy, Edward [mailto:[EMAIL PROTECTED]]
Sent: 07 December 2000 11:06
To: 'jBoss'
Subject: RE: Re[2]: [jBoss-User] Security
Ah ha! How is just as I start worrying about the next thing you manage to
answer it (in this case the inefficiency of authenticating on each method
call).
Thanks for all your help :-)
-----Original Message-----
From: Oleg Nitz [mailto:[EMAIL PROTECTED]]
Sent: 07 December 2000 10:06
To: jBoss
Subject: Re[2]: [jBoss-User] Security
Hi Edward,
Kenworthy, Edward wrote:
KE> That's interesting, because it confirms what I was beginning to suspect,
KE> namely that authentication doesn't occur at login (!) but only when you
try
KE> and do something. Perhaps "login" is a misnomer ? Something like "attach
KE> security associaion to the current thread" would be better ;-)
Authentication is performed on each method call. But the server
login module is called only on the first call, then user/password info
is put to the cache. For now the cache is never purge, but such
possibility should be added in the future.
Note: jBoss is stateless, in general it doesn't hold the list of users
than have logged in, and there is no such thing as user logout.
Thus, "login" is a misnomer from some point of view.
>From other it's not :-)
Best regards,
Oleg
KE> -----Original Message-----
KE> From: Scott M Stark [mailto:[EMAIL PROTECTED]]
KE> Sent: 07 December 2000 05:03
KE> To: jBoss
KE> Subject: Re: [jBoss-User] Security
KE> A little contribution to this security discussion. I have created a
sequence
KE> diagram showing
KE> the steps involved with the client's setup of the security context used
for
KE> the jBoss
KE> calls. This only includes the org.jboss.security.ClientLoginModule and
the
KE> diagram
KE> shows that this module just sets up the jboss client side environment to
KE> marshall the
KE> Principal and password obtained from the CallbackHandler implemented by
the
KE> client application. Most likely one would have a second LoginModule
KE> implementation
KE> to validate the credentials rather than waiting for calls to fail when
any
KE> server side
KE> LoginModule performs validation(at least I would).
KE> One this I saw in going through the ClientLoginModule is that the
logout()
KE> method
KE> does not clear the SecurityAssociation state as the abort() method does.
KE> This means
KE> that once the user has performed a login(), they remain that user for
the
KE> duration of
KE> client, even after a logout(). Shouldn't logout() clear the
KE> SecurityAssociation state as well?
KE> PS, the list won't allow attachments to be sent so where should I place
the
KE> diagram? As
KE> a documentation bug attachment?
KE> --
KE> --------------------------------------------------------------
KE> To subscribe: [EMAIL PROTECTED]
KE> To unsubscribe: [EMAIL PROTECTED]
KE> Problems?: [EMAIL PROTECTED]
KE> --
KE> --------------------------------------------------------------
KE> To subscribe: [EMAIL PROTECTED]
KE> To unsubscribe: [EMAIL PROTECTED]
KE> 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]
