Re: Security Propagation

2002-04-05 Thread Craig R. McClanahan



On Fri, 5 Apr 2002, Jason Owens wrote:

 Date: Fri, 5 Apr 2002 01:28:28 -0800
 From: Jason Owens [EMAIL PROTECTED]
 Reply-To: Tomcat Users List [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Subject: Security Propagation

 I'm interfacing a servlet-based front end to an EJB back end (isn't
 everybody?) using tomcat + jboss. My issue is that I need to
 authenticate using my EJB security bean, but I want to associate the
 resulting subject with the users session in tomcat (as if I had
 performed container authentication). Are custom realms the ONLY way to
 do this (ugh)?

I don't know the JBoss integration code, but I imagine the answer would be
yes, since you're trying to manage the Principals that Tomcat uses to
make security decisions.

 Is there any way to cache the subject in the session, and
 just somehow associate it with the thread's security context (sounds
 like this would be easier) when processing? I haven't found any good
 docs on writing a custom realm, has anyone written any?


Best bet is to look at the existing examples, like JDBCRealm and
JNDIRealm.

However, to store stuff in the user session, you'll probably need to write
custom Authenticator subclasses as well.  Realms don't have access to
anything about the current request or session.

 Any help/pointers/solutions will be appreciated. Thanks


I suppose there is some reason that standard container managed security is
not sufficient ...

 -Jason

Craig


--
To unsubscribe:   mailto:[EMAIL PROTECTED]
For additional commands: mailto:[EMAIL PROTECTED]
Troubles with the list: mailto:[EMAIL PROTECTED]




Re: Security Propagation

2002-04-05 Thread Jason Owens

To answer your assumption, I do have custom security needs beyond 
standard container security (like permission-based functionality). I 
guess my main concern was associating the user's principal with the 
security identity in EJB calls. According to the servlet spec, SRV.12.7, 
a security identity/principal must always be provided for use in a call 
to an enterprise bean. It's not clear on how this is done...

I take it from my research so far that if I want to implement any of 
this stuff, it's going to be proprietary to a specific container.  I see 
that the AuthenticatorBase stores the principal in the session, but 
where does the security context get loaded? or does it? How does the 
container manage the EJB calls? I think I'm just mainly curious, since 
the specification is so vague. But I would like to make my app as 
portable as possible...

Am I trying to do something you're not supposed to do? I did see an 
example of what I need in the book Special Edition Using EJB 2.0... 
however, they simply mention that because they weren't using 
container-managed security on the web app side, you need to associate 
the principal with the thread's security context in order to propagate 
it through the EJB calls. No details.

If this is off topic or something, please let me know - I've never 
actually used mailing lists / forums before.

Thanks - Jason


On Friday, April 5, 2002, at 09:15  AM, Craig R. McClanahan wrote:

 I don't know the JBoss integration code, but I imagine the answer would 
 be
 yes, since you're trying to manage the Principals that Tomcat uses to
 make security decisions.

 Is there any way to cache the subject in the session, and
 just somehow associate it with the thread's security context (sounds
 like this would be easier) when processing? I haven't found any good
 docs on writing a custom realm, has anyone written any?


 Best bet is to look at the existing examples, like JDBCRealm and
 JNDIRealm.

 However, to store stuff in the user session, you'll probably need to 
 write
 custom Authenticator subclasses as well.  Realms don't have access to
 anything about the current request or session.

 Any help/pointers/solutions will be appreciated. Thanks


 I suppose there is some reason that standard container managed security 
 is
 not sufficient ...

 -Jason

 Craig


 --
 To unsubscribe:   mailto:[EMAIL PROTECTED]
 For additional commands: mailto:[EMAIL PROTECTED]
 Troubles with the list: mailto:[EMAIL PROTECTED]



--
To unsubscribe:   mailto:[EMAIL PROTECTED]
For additional commands: mailto:[EMAIL PROTECTED]
Troubles with the list: mailto:[EMAIL PROTECTED]




Re: Security Propagation

2002-04-05 Thread Craig R. McClanahan



On Fri, 5 Apr 2002, Jason Owens wrote:

 Date: Fri, 5 Apr 2002 10:23:27 -0800
 From: Jason Owens [EMAIL PROTECTED]
 Reply-To: Tomcat Users List [EMAIL PROTECTED]
 To: Tomcat Users List [EMAIL PROTECTED]
 Subject: Re: Security Propagation

 To answer your assumption, I do have custom security needs beyond
 standard container security (like permission-based functionality). I
 guess my main concern was associating the user's principal with the
 security identity in EJB calls. According to the servlet spec, SRV.12.7,
 a security identity/principal must always be provided for use in a call
 to an enterprise bean. It's not clear on how this is done...

 I take it from my research so far that if I want to implement any of
 this stuff, it's going to be proprietary to a specific container.  I see
 that the AuthenticatorBase stores the principal in the session, but
 where does the security context get loaded? or does it? How does the
 container manage the EJB calls? I think I'm just mainly curious, since
 the specification is so vague. But I would like to make my app as
 portable as possible...

 Am I trying to do something you're not supposed to do? I did see an
 example of what I need in the book Special Edition Using EJB 2.0...
 however, they simply mention that because they weren't using
 container-managed security on the web app side, you need to associate
 the principal with the thread's security context in order to propagate
 it through the EJB calls. No details.

 If this is off topic or something, please let me know - I've never
 actually used mailing lists / forums before.


I think your basic point (it is going to be proprietary to a specific
container) is correct.  In particular, the container we're talking
about here is the *combination* of Tomcat and the EJB layer from JBoss.
Since I have no clue how this integration was done even for standard
container managed security, I'm afraid I cannot offer any advice on the
details.  Perhaps someone on the JBoss list (since they did the
integration) can help.

 Thanks - Jason

Craig


--
To unsubscribe:   mailto:[EMAIL PROTECTED]
For additional commands: mailto:[EMAIL PROTECTED]
Troubles with the list: mailto:[EMAIL PROTECTED]




Re: Security Propagation

2002-04-05 Thread Jason Owens

I apologize for continuing this thread - but... actually, I am using 
Tomcat stand-alone. Tomcat runs on one machine, JBoss on another. I am 
not using the integrated setup. That's one reason why I am trying to 
investigate this situation, and why I'm writing to the Tomcat list 
instead of JBoss.

Maybe I'm not phrasing my question properly: How does Tomcat (or ANY 
servlet container for that matter) propagate the security information 
for a single session from one JVM (e.g. the servlet runtime) to another 
(e.g. the EJB runtime), especially over a network?

I'll try posting on some other forums. Thanks for the replies :-)
-Jason

On Friday, April 5, 2002, at 11:43  AM, Craig R. McClanahan wrote:

 I think your basic point (it is going to be proprietary to a specific
 container) is correct.  In particular, the container we're talking
 about here is the *combination* of Tomcat and the EJB layer from JBoss.
 Since I have no clue how this integration was done even for standard
 container managed security, I'm afraid I cannot offer any advice on the
 details.  Perhaps someone on the JBoss list (since they did the
 integration) can help.

 Thanks - Jason

 Craig


 --
 To unsubscribe:   mailto:[EMAIL PROTECTED]
 For additional commands: mailto:[EMAIL PROTECTED]
 Troubles with the list: mailto:[EMAIL PROTECTED]



--
To unsubscribe:   mailto:[EMAIL PROTECTED]
For additional commands: mailto:[EMAIL PROTECTED]
Troubles with the list: mailto:[EMAIL PROTECTED]