From user-return-15342-apmail-geronimo-user-archive=geronimo.apache.org@geronimo.apache.org Thu Feb 03 06:45:36 2011
Return-Path:
Delivered-To: apmail-geronimo-user-archive@www.apache.org
Received: (qmail 77309 invoked from network); 3 Feb 2011 06:45:36 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3)
by minotaur.apache.org with SMTP; 3 Feb 2011 06:45:36 -0000
Received: (qmail 7997 invoked by uid 500); 3 Feb 2011 06:45:36 -0000
Delivered-To: apmail-geronimo-user-archive@geronimo.apache.org
Received: (qmail 7753 invoked by uid 500); 3 Feb 2011 06:45:33 -0000
Mailing-List: contact user-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
list-help:
list-unsubscribe:
List-Post:
Reply-To: user@geronimo.apache.org
List-Id:
Delivered-To: mailing list user@geronimo.apache.org
Received: (qmail 7739 invoked by uid 99); 3 Feb 2011 06:45:32 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 03 Feb 2011 06:45:32 +0000
X-ASF-Spam-Status: No, hits=1.5 required=5.0
tests=FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL
X-Spam-Check-By: apache.org
Received-SPF: pass (nike.apache.org: domain of khichi.shailendra@gmail.com designates 74.125.83.182 as permitted sender)
Received: from [74.125.83.182] (HELO mail-pv0-f182.google.com) (74.125.83.182)
by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 03 Feb 2011 06:45:22 +0000
Received: by pvc22 with SMTP id 22so167895pvc.13
for ; Wed, 02 Feb 2011 22:45:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=gamma;
h=domainkey-signature:message-id:date:from:user-agent:mime-version:to
:subject:references:in-reply-to:content-type;
bh=NmThjItVU4Oy0D1/ebRAq5fCtd2FHRTQpydSQsAr7Sc=;
b=Q9j9yWNThhWxBEkSV9dHarzAbywXV+mel/8bnp+SiRmlrBhMqjzGTo6yRJdG2WhAZh
ddDjqUfNMEmbV1aJSeTPsxv3XnyaRCgURutVuZre/QKeBxd/tDFlBt/GDq5RpRzpx9n/
NH4EiZy/BfQUusXJ+oLUkC+gDkSS2R2TCNSiY=
DomainKey-Signature: a=rsa-sha1; c=nofws;
d=gmail.com; s=gamma;
h=message-id:date:from:user-agent:mime-version:to:subject:references
:in-reply-to:content-type;
b=Fym3ncO+62yHUYgZTGzdSHYpR/9XKpEIR//2xePfD/ifhPK4cmq1BY3EZ/ozJC6yS1
ZDL3+HGoGR3hCIw89CKQK2xCwr+qJFYXfmPkvXna/BMGH22E1SRF8C6Xmk1oemFrcxFl
AjK7TLni9fWBm+dyAeo/hOh+5+1k1hvozm10k=
Received: by 10.142.158.14 with SMTP id g14mr10078585wfe.216.1296715501266;
Wed, 02 Feb 2011 22:45:01 -0800 (PST)
Received: from [192.168.1.205] ([115.119.107.2])
by mx.google.com with ESMTPS id y42sm572608wfd.22.2011.02.02.22.44.57
(version=SSLv3 cipher=RC4-MD5);
Wed, 02 Feb 2011 22:44:59 -0800 (PST)
Message-ID: <4D4A4EE7.2080203@gmail.com>
Date: Thu, 03 Feb 2011 12:14:55 +0530
From: Shailen
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7
MIME-Version: 1.0
To: user@geronimo.apache.org
Subject: Re: why we need to provide security realm name to a standalone ejb
client?
References: <4D47E01D.6000301@gmail.com> <40211D3D-4398-411C-B076-A0B7CB44A787@yahoo.com> <1296633399297-2403732.post@n3.nabble.com> <4D4942E8.20308@gmail.com> <4D4A4C05.20009@gmail.com>
In-Reply-To: <4D4A4C05.20009@gmail.com>
Content-Type: multipart/alternative;
boundary="------------010403090607000605020001"
X-Virus-Checked: Checked by ClamAV on apache.org
This is a multi-part message in MIME format.
--------------010403090607000605020001
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Again, geronimo is a system once I have authenticated myself to the
system, then I am allowed to access application. But each
component(example EJBs) will define its own authorization. If I have
authorized myself to the component then I can access components. So the
security is fine.
Now to call an EJB from a standalone client without passing the
security-realm is the question.
First look says what David is suggesting seems reasonable.
May need more brain storming here.
Regards,
Shailen (khichi.shailendra@gmail.com)
+91-9216020360
Mohali, Chandigarh - 160062
On Thursday 03 February 2011 12:02 PM, Shailen wrote:
> ohh.. So jndi tree gets created when we create InitialContext.
>
> I found something which you might be aware already.
> I have created a test security-realm. Now if I try to access my ejb
> with this security-realm it is allowing me to access the object. But I
> dont want this. My EJB is not secured this way.right ?
> I mean this is fishy as I dont want my EJB to be accessed by anyone
> else using another security realm.
> Actually this is hack in security.
> May be we need to think more on other possible ways to escape from
> this hack.
>
> Regards,
> Shailen (khichi.shailendra@gmail.com)
> +91-9216020360
> Mohali, Chandigarh - 160062
>
> On Wednesday 02 February 2011 11:15 PM, David Jencks wrote:
>> The current ejb security is set up so that you need to have some
>> credentials in some security realm in order to get the jndi tree.
>>
>> I think you are asking for a set up so that you can get the jndi tree
>> without any credentials but when you try to do a lookup you need to
>> supply credentials appropriate for the object you are looking up.
>>
>> At the moment I believe you can arrange to bind ejbs at any name you
>> want. In particular you can bind ejbs from different apps in the
>> same subcontext.
>>
>> What do you want to have happen when you try to list this subcontext,
>> but you only have permission to access some of the contents?
>>
>> thanks
>> david jencks
>>
>> On Feb 2, 2011, at 3:41 AM, Shailen wrote:
>>
>>> Yes Juergen, I second you.
>>> I have fixed my problem and I am happy to see geronimo has
>>> implemented what you have said for webservices. see below:
>>>
>>>
>>>
>>> SampleImp
>>>
>>> sample-realm
>>> sample-realm
>>> NONE
>>> BASIC
>>>
>>>
>>>
>>>
>>> This is the code in openejb-jar.xml. Here we are explicitly
>>> defining to use sample-realm for webservice exposed by SampleImp
>>> EJB. I am able to call the webservice using the principal credentials.
>>>
>>> I am still not very sure why geronimo can't geronimo has
>>> like follows:
>>>
>>>
>>>
>>> SampleImp
>>>
>>> sample-realm
>>>
>>>
>>>
>>>
>>> Can someone please put more light on it?
>>>
>>> Regards,
>>> Shailen (khichi.shailendra@gmail.com)
>>> +91-9216020360
>>> Mohali, Chandigarh - 160062
>>>
>>> On Wednesday 02 February 2011 01:26 PM, weberjn wrote:
>>>> One could rather argue that a client should not know about an ejb's security
>>>> configuration. This should be only known in the ejb configuration, and
>>>> nowhere else, definitivly not on the client. The ejb deployer should be able
>>>> to switch from one security realm to another, without the client knowing.
>>>>> there's no easy way to predict which application's ejb or which ejb you
>>>>> want to call
>>>> I understand this is because security lookup is done during creation of the
>>>> InitialContext and the lookup with JNDI name is done in the next call.
>>>>
>>>> An alternative would be to define an order of security realm lookups.
>>>>
>>>> Greetings,
>>>> Juergen
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> David Jencks wrote:
>>>>> This is the right place to ask this question.
>>>>>
>>>>> Geronimo lets you set up many security realms at once. When you connect
>>>>> from a remote client to call ejbs, there's no easy way to predict which
>>>>> application's ejb or which ejb you want to call. So you have to specify
>>>>> how you want to log in when you connect.
>>>>>
>>>>> We could allow specifying a default security realm for all of openejb so
>>>>> if you don't specify a realm we use the default.
>>>>>
>>>>> thanks
>>>>> david jencks
>>>>>
>>>>> On Feb 1, 2011, at 2:27 AM, Shailen wrote:
>>>>>
>>>>>> Hi All,
>>>>>>
>>>>>> I have a very simple ejb deployed on geronimo2.2.1. This ejb is secured
>>>>>> by a security realm(Database(SQL) realm). When I call this ejb from a
>>>>>> standalone java client, it restricts me from accessing it without
>>>>>> authentication.
>>>>>>
>>>>>> But when I provide this principal and credentials then also it restricts
>>>>>> me from calling this ejb.
>>>>>> When I additionally provide realmName then it enables me to call this
>>>>>> ejb.
>>>>>>
>>>>>> My question is why do we need to provide the security realm name in the
>>>>>> client?
>>>>>>
>>>>>> I am sorry if this is not the right place to ask such questions.
>>>>>> --
>>>>>>
>>>>>> Regards,
>>>>>> Shailen (khichi.shailendra@gmail.com)
>>>>>> +91-9216020360
>>>>>> Mohali, Chandigarh - 160062
>>
--------------010403090607000605020001
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Again, geronimo is a system once I have authenticated myself to the
system, then I am allowed to access application. But each
component(example EJBs) will define its own authorization. If I have
authorized myself to the component then I can access components. So
the security is fine.
Now to call an EJB from a standalone client without passing the
security-realm is the question.
First look says what David is suggesting seems reasonable.
May need more brain storming here.

I found something which you might be aware already.
I have created a test security-realm. Now if I try to access my
ejb with this security-realm it is allowing me to access the
object. But I dont want this. My EJB is not secured this way.right
?
I mean this is fishy as I dont want my EJB to be accessed by
anyone else using another security realm.
Actually this is hack in security.
May be we need to think more on other possible ways to escape from
this hack.

The current ejb security is set up so that you need
to have some credentials in some security realm in order to get
the jndi tree.

I think you are asking for a set up so that you can get the
jndi tree without any credentials but when you try to do a
lookup you need to supply credentials appropriate for the
object you are looking up.

At the moment I believe you can arrange to bind ejbs at any
name you want. In particular you can bind ejbs from different
apps in the same subcontext.

What do you want to have happen when you try to list this
subcontext, but you only have permission to access some of
the contents?

thanks

david jencks

On Feb 2, 2011, at 3:41 AM, Shailen wrote:

Yes Juergen, I
second you.
I have fixed my problem and I am happy to see geronimo
has implemented what you have said for webservices. see
below:

One could rather argue that a client should not know about an ejb's security
configuration. This should be only known in the ejb configuration, and
nowhere else, definitivly not on the client. The ejb deployer should be able
to switch from one security realm to another, without the client knowing.

there's no easy way to predict which application's ejb or which ejb you
want to call

I understand this is because security lookup is done during creation of the
InitialContext and the lookup with JNDI name is done in the next call.
An alternative would be to define an order of security realm lookups.
Greetings,
Juergen
David Jencks wrote:

This is the right place to ask this question.
Geronimo lets you set up many security realms at once. When you connect
from a remote client to call ejbs, there's no easy way to predict which
application's ejb or which ejb you want to call. So you have to specify
how you want to log in when you connect.
We could allow specifying a default security realm for all of openejb so
if you don't specify a realm we use the default.
thanks
david jencks
On Feb 1, 2011, at 2:27 AM, Shailen wrote:

Hi All,
I have a very simple ejb deployed on geronimo2.2.1. This ejb is secured
by a security realm(Database(SQL) realm). When I call this ejb from a
standalone java client, it restricts me from accessing it without
authentication.
But when I provide this principal and credentials then also it restricts
me from calling this ejb.
When I additionally provide realmName then it enables me to call this
ejb.
My question is why do we need to provide the security realm name in the
client?
I am sorry if this is not the right place to ask such questions.
--
Regards,
Shailen (khichi.shailendra@gmail.com)
+91-9216020360
Mohali, Chandigarh - 160062