Hi Phillipe,
do you have any estimates when the release of Jonas with these security
features is planned?
Our applications has very tight requirements for security. Most of our
security is content based and therefore cannot be specified declaratively
using deployment descriptors but it has to be specified programmatically. We
are at the point when we need to include security features into our code.
Therefore the only feature we really need is the getCallerPrincipal() method
to find out who is accessing the beans. This requires of course definition
of what principal is, how it gets associated with current request,
propagated between different beans and so on...
I am willing to help with implementing of this feature if it helps you. Can
you give me some insight about your ideas, plans, designs or maybe some
hints where to start looking.
Maybe at the beginning it is enough to do something simple just to get it
working. For example Weblogic is using following solution:
this is excerpt from Weblogic documentation which can be found at
http://www.weblogic.com/docs51/classdocs/API_jndi.html#principal
<<
...
java.naming.security.principal. (In the example, we use the constant
Context.SECURITY_PRINCIPAL for this property name.) Set the value for this
property name to specify the identity of the principal (user) for security
purposes. Value defaults to "guest" unless the thread has already been
associated with a principal. See Associating a principal with a thread.
java.naming.security.credentials. (In the example, we use the constant
Context.SECURITY_CREDENTIALS for this property name.) Set the value for this
property name to specify the password for the principal, or, alternatively,
an Object that implements the weblogic.security.acl.UserInfo interface, with
the property java.naming.security.credentials. If you pass a UserInfo object
in this property, the property java.naming.security.principal is ignored.
Value defaults to "guest" unless the thread has already been associated with
a principal. See Associating a principal with a thread.
...
Associating a principal with a thread
In order to perform work that requires authentication or access control, you
must associate a principal, or user, with the thread that will perform the
work. To do so, create a context with the appropriate principal and
credential property values as described in the sections above. To
disassociate a principal with the thread, close the context.
When a thread is associated with a principal, that principal becomes the
default for the thread. If any contexts are subsequently created without
principal or credential properties, the principal associated with the thread
will remain unchanged.
While it is technically possible to share a single context among multiple
threads, passing a context to another thread does not associate the
principal used in creating the context with the new thread. The only way to
associate a principal with a new thread is to create a new context within
that thread. In addition, a context can only be closed within the thread
with which it was created. For these reasons, it is strongly suggested that
all work performed with a given context be handled in the same thread.
A thread may be associated with only one principal at any given time. If
multiple contexts are created within a single thread without closing any
contexts, the thread will be associated with the principal used in the last
context created. principal information is stored with the thread in a stack.
If the last context is closed, the thread becomes associated with the
principal used in creating previous context, and so on.
>>
Best Regards,
Miroslav Halas
Software Engineer
Compuware Corp.
15305 Dallas Parkway
Suite 900
Addison, TX 75001
phone 9720-960-0960 x 1333
fax 972-960-8489
-----Original Message-----
From: Philippe Durieux [mailto:[EMAIL PROTECTED]]
Sent: Monday, May 22, 2000 3:37 AM
To: Tobias Seelinger
Cc: [EMAIL PROTECTED]
Subject: Re: Passing Principal between Beans
Tobias Seelinger wrote:
>
> Does Jonas 2.0 support java.security.Principal ? It seems not to work
> because getCallerPrincipal() returns Null.
>
> I have tried to pass the name of the current user and/or the current
> language from a Session Bean to an Entity Bean. The Entity Bean is a BMP
> Bean and creates a SQL Query dependent on the language. I don't want to
> use parameters in my Business Methods for the language/user name. So I
> want to transmit these attributes via the EJBContext. According to the
> EJB Specification this should be possible with java.security.Principal.
>
> Has someone a better idea how to solve this ?
>
> regards,
>
> Tobias Seelinger
Hi Tobias,
getCallerPrincipal(), isCallerInRole(), and all other security features
will be implemented in a next version of JOnAS. This requires to defines
what is a Principal, what is the security Context we must pass between
JVMs, how roles are mapped, etc...
You will have to wait for JOnAS 2.1 or 2.2 to get these security
features.
Sorry about that!
Philippe
--
Philippe Durieux ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Bull S.A - 1 rue de Provence - 38432 Echirolles Cedex France
[EMAIL PROTECTED] http://www-frec.bull.com
-> Download our EJBServer at http://www.bullsoft.com/ejb <-
----
To unsubscribe, send email to [EMAIL PROTECTED] and
include in the body of the message "unsubscribe jonas-users".
For general help, send email to [EMAIL PROTECTED] and
include in the body of the message "help".
----
To unsubscribe, send email to [EMAIL PROTECTED] and
include in the body of the message "unsubscribe jonas-users".
For general help, send email to [EMAIL PROTECTED] and
include in the body of the message "help".
