Hi Bishnu,
Sorry for the slow reply, River is maintained by volunteers, we don't
have as much time as we'd like. Your service browser is interesting.
There are significant challenges with security, River (Jini) has
constraints, which allow clients and services to require integrity,
confidentiality and minimum server or client principals. You may find
constraints very useful, these could be supported in your browsers
security settings.
JERI has superceded RMI in Jini, it's the standard for exporting service
objects and allows an administrator to select from pluggable Exporters
that use different protocols, including RMI, IIOP, TLS etc. JERI is
required for constraints.
During object serialization there is a window of time where objects are
created and class loading occurs, prior to a ProtectionDomain
representing them being pushed onto the execution stack, allowing an
attacker to take advantage of privileges the current execution stack
has, this is the mechanism for java deserialisation privilege escalation
attacks reported recently by popular media. To avoid this
vulnerability, permissions must be minimised during deserialisation.
JAAS in its standard implementation, injects Principals into all
ProtectionDomain on the call stack (which must have sufficient privilege
for it to occur). ProtectionDomains added to the stack after login and
Subject.doAs, are not injected, but may be subject to deserialisation
attacks if and when local code is privileged. A user login adds
permission to existing ProtectionDomains, which may all be privileged in
any case. I've proposed for distributed environments that this
behaviour be changed so a ProtectionDomain representing the Subject be
pushed onto the stack instead, allowing a user to have a different alias
for browsing untrusted networks, where the user has restricted
permission to prevent deserialisation privilege escallation attacks on
client or server jvm's, even when the jvm or application code would
otherwise be vulnerable. This could be supported as a list of
permissions the user has selected for the alias on clients, or by being
granted a particular principal on servers. This would greatly simplify
configuring java permissions.
Deserialisation is still subject to denial of service (out of memory
error or stack overflow), however this is only of inconvenience value,
the jvm can be easily killed and restarted.
Trust in a community is based on identity and observed behaviour.
SPKI has an interesting authorisation delegation model, allowing users
to remain anonymous while avoiding the need for Certificate
Authorities. An example use case: a company delegates authority to
access external resources to its employees with short term tickets;
certificates that expire daily. A company or household may hold a
contract with a supplier for a resource, this may expire on monthly or
annual contract terms, during login, resources may be allocated on a
daily basis by creating a certificate chain that delegates permission,
every time a user logs in.
org.apache.river.api.security.PermissionGrant is a stateless abstract
class (originally designed as an interface, enforcing security was
complex, so an abstract class was chosen instead) that would also allow
standard java Permissions to be granted and expire. There is a
DelegatePermission framework (implementation to be distributed
separately) and caching DelegateSecurityManager that for example,
enables Li Gong's method guard pattern to be applied to existing Socket
implementations using a SocketFactory wrapper.
Which reminds me; I need to create a directory on svn for the delegates
implementation.
These things are low level, what is needed is a simplifying upper layer
that makes using services in the service browser simple and secure.
To achieve goals you've set in the paper, there's plenty of work left to do.
Best Regards,
Peter.
Bishnu Gautam wrote:
Hi
No, I am not using ServiceUI, instead, I have written myself that exports the
wrapped services to the client. We can still export the very light weight
browser as jini service too. In that way, we can still make our jini services
that can run in client machine. I am calling this browser as Universal Browser.
I have written a paper about this scenario more in detail at following paper:
http://www.iaeng.org/publication/IMECS2010/IMECS2010_pp638-643.pdf
You may find number of services running in the browser including web browser. Yes, this is the right time how we can make good service interface that can be used by client at end.
RegardsBishnu
Bishnu Prasad Gautam
Date: Tue, 4 Sep 2012 08:12:24 +0100
Subject: Re: WELCOME to [email protected]
From: [email protected]
To: [email protected]
Can you say a little more about the JPanel wrapping? Are you making use of
ServiceUI or custom generating something or ?
The reason I'm asking is because for client-side exposure of graphical
material, a browser is a good place to go especially with the arrival of
HTML5. In fact, perhaps it's time we re-evaluated ServiceUI...
On 4 September 2012 01:26, Bishnu Gautam <[email protected]> wrote:
Hi Peter and Simon
Thanks for messages.Yes, I was thinking of DNS-SRV discovery. Also, UDT is
better than TCP. I am very interested to use Java UDT and totally agree to
apply this protocol. That will efficiently work I think. I am building an
application that transfer all bundled JPanel wraped jini/river services to
client sides. I am able to execute it in muliti-Lan environment. I will
donate this code to river community. My next phase is to implement it to
execute in internet. If you guys have already implemented some of it, lets
share the codes or lets discuss so that we can bring river project as one
of the demanding solution not only in distributed environment but also for
the cloud community. I think this is the right time for jini/river
community to come into the business or into the cloud.
RegardsBishnu
Bishnu Prasad Gautam
Date: Mon, 3 Sep 2012 18:12:55 +1000
From: [email protected]
To: [email protected]
Subject: Re: WELCOME to [email protected]
Thanks Bishnu, welcome to River!
I've had some plans with regard to internet based services, not much
implemented I'm afraid, time constraints...
1. org.apache.river.api.lookup.StreamServiceRegistrar - interface for
internet based service registrars (lookup service).
2. DNS-SRV Discovery, to use in place of multicast discovery, this
(not yet implemented) discovers the location of lookup services,
to be used in Unicast Discovery.
3. Java UDT Sockets - not yet implemented, this is basically Data
over UDP, which is easier to get through firewalls than TCP.
Regards,
Peter.
Bishnu Gautam wrote:
Hello River Team
It seems that Jini is getting its pace in terms of River. This is good
indication and I think that River has great potential if we can build some
application that can interact over Internet.I am planning to do a research
work whether we can make an application of River that can interact over
internet as I found there are some issues of firewall etc. Would you let me
know, whether the River team has plan of bringing River on the Internet ?
Bishnu Prasad Gautam
Date: Sun, 2 Sep 2012 00:48:45 +0000
From: [email protected]
To: [email protected]
Subject: WELCOME to [email protected]
Hi! This is the ezmlm program. I'm managing the
[email protected] mailing list.
I'm working for my owner, who can be reached
at [email protected].
Acknowledgment: I have added the address
[email protected]
to the dev mailing list.
Welcome to [email protected]!
Please save this message so that you know the address you are
subscribed under, in case you later want to unsubscribe or change your
subscription address.
--- Administrative commands for the dev list ---
I can handle administrative requests automatically. Please
do not send them to the list address! Instead, send
your message to the correct command address:
To subscribe to the list, send a message to:
<[email protected]>
To remove your address from the list, send a message to:
<[email protected]>
Send mail to the following for info and FAQ for this list:
<[email protected]>
<[email protected]>
Similar addresses exist for the digest list:
<[email protected]>
<[email protected]>
To get messages 123 through 145 (a maximum of 100 per request), mail:
<[email protected]>
To get an index with subject and author for messages 123-456 , mail:
<[email protected]>
They are always returned as sets of 100, max 2000 per request,
so you'll actually get 100-499.
To receive all messages with the same subject as message 12345,
send a short message to:
<[email protected]>
The messages should contain one line or word of text to avoid being
treated as sp@m, but I will ignore their content.
Only the ADDRESS you send to is important.
You can start a subscription for an alternate address,
for example "[email protected]", just add a hyphen and your
address (with '=' instead of '@') after the command word:
<[email protected]>
To stop subscription for this address, mail:
<[email protected]>
In both cases, I'll send a confirmation message to that address. When
you receive it, simply reply to it to complete your subscription.
If despite following these instructions, you do not get the
desired results, please contact my owner at
[email protected]. Please be patient, my owner is a
lot slower than I am ;-)
--- Enclosed is a copy of the request I received.
Return-Path: <[email protected]>
Received: (qmail 76169 invoked by uid 99); 2 Sep 2012 00:48:45 -0000
Received: from athena.apache.org (HELO athena.apache.org)
(140.211.11.136)
by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 02 Sep 2012
00:48:45 +0000
X-ASF-Spam-Status: No, hits=2.4 required=5.0
tests=FREEMAIL_ENVFROM_END_DIGIT,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: domain of [email protected]
65.55.90.77 as permitted sender)
Received: from [65.55.90.77] (HELO snt0-omc2-s2.snt0.hotmail.com)
(65.55.90.77)
by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 02 Sep 2012
00:48:36 +0000
Received: from SNT145-W136 ([65.55.90.71]) by
snt0-omc2-s2.snt0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675);
Sat, 1 Sep 2012 17:48:15 -0700
Message-ID: <[email protected]>
Content-Type: multipart/alternative;
boundary="_8d4cc292-55ff-42a6-92f3-b39be91ffb52_"
X-Originating-IP: [122.18.73.194]
From: Bishnu Gautam <[email protected]>
To:
<dev-sc.1346546661.bpbohbfainpplmmplpaj-bishnu35=
[email protected]>
Subject: RE: confirm subscribe to [email protected]
Date: Sun, 2 Sep 2012 00:48:15 +0000
Importance: Normal
In-Reply-To: <[email protected]>
References: <[email protected]>
MIME-Version: 1.0
X-OriginalArrivalTime: 02 Sep 2012 00:48:15.0984 (UTC)
FILETIME=[A3545700:01CD88A4]
X-Virus-Checked: Checked by ClamAV on apache.org
