Re: ClientMinPrincipal versus ClientMaxPrincipal

Mark Brouwer wrote:
>>> Min(A) allows the possibility of authenticating as additional
>>> principals;
>>> Max(A) does not.  But that possibility only matters if the RMI impl is
>>> capable of multi-principal authentication; the standard JERI transports
>>> are not.
>>
>>
>> Where would be a good place to document this issue so that this potential
>> different behavior is more explicitly discussed?  I'm contemplating a
>> new IL
>> factory which would transport all Principals except those enumerated by a
>> constraint, and it sounds like I might be able to get what I need by
>> using a
>> slightly different implementation which might fit into the existing code
>> and be
>> driven by an additional constraint.
>
> Can't you use ClientMaxPrincipal in this case Gregg? Is there a
> particular reason why you want to express the principals you don't want
> to expose versus the principals you are willing to expose to the server.

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.  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).  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.

I'm still thinking through all of this...

Gregg Wonderly

--------------------------------------------------------------------------
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]