[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrp-interop] Re: [wsrp] Anonymous User
Richard, given your other e-mail concerning environments that reject
messages that don't have the Username token I am not sure what you are
suggesting is the interoperable (standard) solution. I.e. I am looking
for what the standard/default consumer behavior should be unless it is
otherwise informed/configured. Are we really going to demand that
producers have duplicate ports just to receive anonymous requests?
Wouldn't it be cleaner if manufactured a standard UserName token to
signify this (wsrp-minimal?) or demand the producer handle the lack of
the Username token? -Mike- Richard Jacob wrote: right. So a mixed environment would either require a policy definition which would be able to express this or by having to port definitions and annotate them accordingly. Mit freundlichen Gruessen / best regards, Richard Jacob ______________________________________________________ IBM Lab Boeblingen, Germany Dept.8288, WebSphere Portal Server Development WSRP Technical Lead WSRP Standardization Phone: ++49 7031 16-3469 - Fax: ++49 7031 16-4888 Email: mailto:richard.jacob@de.ibm.com Subbu Allamaraju <subbu@bea.com> To 08/14/06 05:39 PM cc wsrp-interop@lists.oasis-open.org Subject Re: [wsrp-interop] Re: [wsrp] Anonymous User Not supplying a security token is the most ideal, since by doing so, the sender is telling the producer that either that it does not know who the user is, or that it cannot generate one. The producer then has a choice - it could either interpret lack of the token to mean an anonymous user, or reject the message altogether. I would expect a WSDL policy attachment to specify which way the producer intends to behave. Subbu Rich Thompson wrote:I suspect most systems default to the guest user (if allowed) when no user credentials are supplied. Is anyone aware of systems not following this behavior? Rich *Nathan Lipke <nlipke@bea.com>* 08/08/2006 01:36 AM To Michael Freedman <michael.freedman@oracle.com> cc wsrp <wsrp@lists.oasis-open.org>,wsrp-interop@lists.oasis-open.orgSubject Re: [wsrp] Anonymous User True, WS-Security does not account for anonymous/guest users. SAML suffers from the same issue. I'm a little concerned about using a string for the username as it may interfere with existing username token implementations. Perhaps we should sign something else (the body or a timestamp) in the case of the anonymous user. -- Nate Michael Freedman wrote: > Folks, it doesn't look like there is a formal convention in > WS-Security to pass an anonymous/guest user identity particularly when > relying on UserName Token or Username token with password. Am I > mistaken? If not I wonder if there is an accidental convention in our > wsrp implementations -- what if anything do you do in this regards? > > To be clear we are concerned about a situtation in which the consumer > identifies itself to the producer (via a digital signature) and wants > to use the UserName Token mechanism to identify the user on whose > behalf this consumer is making the request. We want a known > form/value that (wsrp) intercepters/the security system (if it > supports such a concept) will map to an anonymous user/guest. Should > this be (a nil) the lack of a UserName token? A UserName token whose > value is ""? A Username token whose value is wsrp:minimal? Any of > these? > -Mike- _______________________________________________________________________ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]