Thanks.... I'll try to read the JBoss Architecture.
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Sandeep Dath
Sent: Friday, December 01, 2000 3:36 PM
To: jBoss Developer
Subject: RE: [jBoss-Dev]
>Yup.
>
>-- Which one are you refering? does Jboss has its own
>servlet/jsp container?
Sorry. Yeah you need to use Tomcat/Jetty.
>> If I need to use jetty or tomcat, do they
>>support j_security_check? If no, what's the alternative? I
>>have my username,
>>password and role stored in a database that is actually used
>>by Weblogic
>>RDBMSRealm.
>
>Realms in Weblogic are a sort of feature that is difficult to
>find in open
>source per se. Additionally, when you are working with
>alternate realms, as
>you are (RDBMSRealm works with an RDBMS and is an alternative
>realm) - you
>will perhaps have enabled realm caching (hosted by CachingReal
>etc etc etc).
>
>
>Plus, this is really not portable. I guess you are constrained
>by time and
>don't want to implement a custom authentication system. Jboss, uses a
>security interceptor to do security checking, picking up info
>from the XML
>descriptor. It is theoretically possible to implement a
>security plugin that
>will pick up the ACLs from an RDBMS just like WebLogic does in
>the case of
>RDBMSRealm.
>
>-- If I want to implement my own security plugin or my own RDBMS realm,
>where should I start? How do you specify the role of the
>authenticated user
>to JBoss?
>
Well I wouldn't call it a realm here. Essentially, JBoss is completely
componentized. For example, if you wanted to support a different
distribution protocol (say DCOM though heaven forbid such a thought!), you
can do that by providing a plugin for that. The ContainerInvoker can use
whatever distribution protocols are supported through plugin
implementations.
Similarly, the SecurityInterceptor determines what to do with incoming calls
to the container from a security perspective. It does this on the basis of
ACL information retrieved from wherever that information (specified by
deployer) is stored. Theoretically any form of persistent storage could be
used for that. Right from interfaces with ADSI, LDAP, Netscape Directory
through (O)RDBMSs etc etc etc. The "strategy" that is used to implement a
particular horizontal segment of JBoss functionality (security,
distribution, instance syncing, transaction support etc) is determined
declaratively using information from the XML descriptors. All you have to do
to provide a different strategy for any of these is to implement your own
plugin.
The JBoss code is quite self-documenting. You could take a look at the
container architecture outline doc (link available I think on the Docs page)
for a more formal and detailed statement of the above. Plus if you want to
implement a plugin, I guess the JBoss dev team will be more that willing to
help you get started. Furthermore, since this is open source, you could
contribute to the project as well.
Specifically in the case of JBoss/Tomcat integration, I think you could buzz
Aaron or Rickard and I guess they could help you out much better. I am just
a measly user. ;-)
Thanks and regards,
Sandeep
"I too seek the light, so long as it tastes great and is not too filling."
- Mostly Anonymous (circa
1997 A.D.)
