Hi Edward,

Kenworthy, Edward wrote:
KE> The reason I was concerned that it would be the whole JVM is what happens if
KE> other apps are running inside it, eg as might happen running web clients.
KE> They all use the same login credentials.
You can run any other apps inside the same JVM, jBoss client login
module doesn't add any Credentials, but set variables in
SecurityAssociation, which is used *only* during access to jBoss
server.

KE> Anyway, that's not a problem as it seems authentication is done by thread -
KE> (which is nearly as horrible; but safer) - now I just have to perform a
KE> login for every thread I create that accesses the server. (Can I re-use the
KE> LoginContext instance I wonder and just call .login() in each thread ?)
Once again: by default the authentication data is set for the whole
JVM. This is good for the ordinary GUI clients, because you would have
problems with access to the server say, from Swing listeners if the
authentication was done by thread (AFAIK they are called from the AWT
thread).
But for web container you can switch to authentication by thread,
you just need to call SecurityAssociation.setServer() for that.

Best regards,
 Oleg 

KE> -----Original Message-----
KE> From: Oleg Nitz [mailto:[EMAIL PROTECTED]]
KE> Sent: 06 December 2000 16:52
KE> To: jBoss
KE> Subject: Re[4]: [jBoss-User] Security


KE> Hi Edward,

KE> Kenworthy, Edward wrote:
KE>> And a second question :-)

KE>> What's the scope of the login ?

KE>> With logging into the appserver using the InitialContext it's reasonably
KE>> obvious - any lookups I perform using the InitialContext (and any
KE> methods I
KE>> invoke on those things I look up etc etc).

KE>> But what's the scope of the JAAS login ? I can't see how it could be
KE>> anything other than the entire JVM
KE> Usually it is for a standalone client.
KE> If you call SecurityAssociation.setServer() the login info becomes
KE> associated with the current thread,
KE> which is useful e.g. for Tomcat security.

KE>> (which appears to be far, far, worse than the InitialContext
KE>> approach so-called kludge). 
KE> Why? I can't get this. You want not merely to access several jBoss
KE> servers, but to do this with different user names?
KE> It sounds a bit schizophrenic :-)
KE> I'd like you to expand on this.

KE> Oleg.

KE>> -----Original Message-----
KE>> From: Oleg Nitz [mailto:[EMAIL PROTECTED]]
KE>> Sent: 06 December 2000 13:02
KE>> To: jBoss
KE>> Subject: Re[2]: [jBoss-User] Security


KE>> Hi Edward,

KE>> Have you read the following message?
KE>>
KE> http://www.mail-archive.com/[email protected]/msg04170.html

KE>> It not, please, read and if you will have any questions after that,
KE>> let me know.

KE>> Oleg.

KE>> Kenworthy, Edward wrote:
KE>>> Actually I'll amend this question if I may :-)

KE>>> I've read and understood all the JAAS stuff (Although it's not clear to
KE>> me
KE>>> how my LoginContext is bound to accessing the EJBs, as Rickard has
KE> asked
KE>>> before, what is the scope ? Why quesiton is, what is the scope and how
KE>> do I
KE>>> set it ?).

KE>>> So for example I now know that to logon I use:

KE>>>         Subject edward = new Subject();
KE>>>         edward.getPrincipals().add(new Principal("Customer"));
KE>>>         edward.getPublicCredentials().add("mypassword");

KE>>>         try
KE>>>         {
KE>>>                 LoginContext edwardLC = new
KE>> LoginContext("EdwardKenworthy",
KE>>> edward);
KE>>>                 LC.login();
KE>>>         }
KE>>>         catch (LoginException le)
KE>>>         {
KE>>>                 // oops
KE>>>         }

KE>>> However, if all I do is this then I get a "java.lang.SecurityException:
KE>>> Unable to locate login configuration".

KE>>> Which makes sense, but now we are into the realms of jBoss specifics.
KE>> What
KE>>> jBoss JAAS login configuration should I be using for my client ? And
KE> how
KE>> do
KE>>> I set it up ?

KE>>> This then leads me onto a related question, for jBoss's implementation
KE>> of
KE>>> JAAS (org.jboss.security.JaasSecurity*.java), how do I manage (CRUD)
KE>> users,
KE>>> credentials(passwords) and roles ?

KE>>> If there's any sample/test client and admin-client code (presumably you
KE>>> wrote such things whilst implementing it) could you make the source
KE>>> available so I can dissect it and work out what to do ? (You never know
KE>> I
KE>>> might even write it up as a HOWTO ;-)

KE>>> Quivering in anticipation

KE>>> Edward

KE>>> -----Original Message-----
KE>>> From: Kenworthy, Edward [mailto:[EMAIL PROTECTED]]
KE>>> Sent: 06 December 2000 10:38
KE>>> To: 'jBoss'
KE>>> Subject: RE: [jBoss-User] Security


KE>>> Ah, ok, now I understand. Thanks.

KE>>> Just one last question :-)

KE>>> If I do what Toby suggested in his original post, ie use JAAS and set
KE>> the
KE>>> two tags <authentication-module> and <role-mapping-manager> to
KE>>> java:/jaas/other then have you any pointers to where I look to find out
KE>> how
KE>>> the client logs on, and how I manage users/passwords/roles. I'm reading
KE>> my
KE>>> way through the documentation available on the javasoft site,
KE>>> http://java.sun.com/products/jaas/, but so far that seems to be focused
KE>> on
KE>>> a) general overview and justification and b) implementers of JAAS (but
KE>>> perhaps I just haven't found the right bit yet).

KE>>> Edward

KE>>> -----Original Message-----
KE>>> From: Rickard �berg [mailto:[EMAIL PROTECTED]]
KE>>> Sent: 05 December 2000 15:30
KE>>> To: jBoss
KE>>> Subject: Re: [jBoss-User] Security


KE>>> Hi!

KE>>> "Kenworthy, Edward" wrote:
>>>> Really ?

KE>>> Really ;-)

>>>> Wow and ouch, I thought it worked like this:
>>>> 
>>>> 1/ get initial context, sets up caller principle.
>>>> 2/ lookup bean.
>>>> 3/ try and invoke a method, app server checks caller principle for
>>>> permission.
>>>> 
>>>> If it works like this, then passing around a reference isn't a problem
KE> as
KE>>> it
>>>> will use your permissions, not any associated with the reference.

KE>>> Depends on what you mean by "sets up caller principal" (note spelling
KE>>> BTW). What is it's scope? The thread? The JVM? The current context
KE>>> classloader? The threadgroup? All valid options, in some sense, but
KE> with
KE>>> wildly different semantics.

>>>> Anyone, assuming you're right ;-), how do I "log-on" to the app server ?

KE>>> 1) Use some proprietary mechanism
KE>>> 2) Use J2EE-valid client containers, i.e. servlets, which has a
KE> standard
KE>>> authentication method
KE>>> 3) Use JAAS

KE>>> /Rickard




KE>> Best regards,
KE>>  Oleg 




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]




KE> Best regards,
KE>  Oleg 




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]

Reply via email to