Re: ClientMinPrincipal versus ClientMaxPrincipal

Gregg Wonderly wrote:

> I want a preparer to be in control, and currently ClientMaxPrincipal does
> provide some of the control if you just want to send one identity.

The way I read ClientMaxPrincipal it does that, to me it doesn't state a
server is only allowed to pick one of the principals that is defined by
the ClientMaxPrincipal, if there are endpoints that want all the
principals part of the constrained subject it should be allowed to do so.

One 'advantage' I see of ClientMaxPrincipal versus
ClientFilterOutPrincipal (that excludes certain principals) is that in
the case a subject changes (more principals added) that none of the new
principals is "freely send out" out, but I agree it also makes it less
flexible.

>                                                                   I am
> thinking about the situation of come as you are computing in a more public
> environment where you might have multiple private identities that you
> don't want
> to freely send out.  So, I want to be able to say "send everything that is
> identity based" but don't send "personal authentication" information
> (usernames
> and passwords for example).

In case the client has knowledge of all its principals (which is very
likely) it won't be hard to write a utility that based on an out-filter
calculates the set of principals that are allowed to be exposed, i.e.
translating it into an ClientMaxPrincipal. But with a change of the
subject it might be necessary to prepare a previously service proxy for
a subsequent time after a new ClientMaxPrincipal has been calculated.

Also I expect a (trusted) secure endpoint to only transfer principals
for which it has a proper AuthenticationPermission, so that is another
way to control the set of principals sent. But that is not a very
reliable way to control the set of principals to be exposed, as in case
the custom secure endpoint is locally available it has likely all
permissions, although I expect there to be a smart proxy in front of it
which might make it work as the permissions are in that case limited by
the ones granted to the class loader associated with the smart proxy.

>                     I also, then want the service constraint which
> might require some such authentication to cause the user to be offered a
> dialog
> that would work similar to the HTTP auth required exchange.

Why would you want to use constraints here, isn't it possible to make
an endpoint session aware, meaning that when the endpoint discovers the
client hasn't logged in yet or doesn't contain a particular principal
type as part of its subject it pops-up a log-in dialog, or some other
form of callback.

I must admit I have no clear idea to make endpoints session aware in a
meaningful way at this moment. I could vaguely remember the Michael
Warres/Daniel Jiang presentation at JCM7 and I was capable to find his
presentation in the webarchives at
http://web.archive.org/web/20040604122754/http://www.jini.org/meetings/seventh/Warres/Warres.pdf
and it seems you can come up with a way to make your endpoints session
aware.

A digest authentication endpoint would be a nice additional endpoint
I guess for some use cases (like your field engineers with notebooks
with ServiceUIs to your services, if I'm right). If you were able to
(mis)use the subject as a container for the session key it wouldn't be
that extremely hard to write, although you never know there is a
subject, you don't have the guarantee it is writable and if it is,
updating it is with the lack of a synchronization strategy a matter of
having good faith. Still I think there are ways to have the endpoint
implementation providing a proper session identifier as shown in the
Warres presentation.

Maybe this is of no help, but as you are still thinking I thought it
could help to share some ideas. If there were a digest authentication
(server)endpoint I'm certainly interested to see support for that
through Seven. A digest authentication endpoint is of course not a very
secure means of communicating, but at least it allows for client
authentication.
--
Mark

--------------------------------------------------------------------------
Getting Started:     http://www.jini.org/wiki/Category:Getting_Started
Community Web Site:  http://jini.org
jini-users Archive:  http://archives.java.sun.com/archives/jini-users.html
Unsubscribing:       email "signoff JINI-USERS"  to [email protected]