[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrp-interop] Re: [wsrp] Anonymous User
We're not talking about an artificial token here.
We're talking about a UserName token defined in the WS-S spec with a
"well-known" value.
The minimalist approach on the producer side is to simple create a user
with this value as the ID and assign it the least access rights.
As said this might impose problems concerning the security context and
backend systems.
Correct concerning the two challanges.
But I would say it's depending on the flexibility and extensibitly of the
security framework.
I would expect that most security frameworks have plugpoints anyway for the
authentication since in most cases customers like to plug in their third
party authentication systems anyway (e.g. some SSO solutions).
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/17/06 03:29 PM Richard Jacob/Germany/IBM@IBMDE
cc
Michael Freedman
<michael.freedman@oracle.com>,
wsrp-interop@lists.oasis-open.org
Subject
Re: [wsrp-interop] Re: [wsrp]
Anonymous User
There are two key challenges:
- Getting the security system on the consumer manufacture the token when
the user is anonymous.
- Getting the security system on the producer consume the token and
interpret the user as being anonymous
Control for these ends typically lie in the security stacks, and
producers/consumers don't have explicit control on this (unless of
course we start hacking around details - but when it comes to security,
I would be careful).
Given these points, I would argue against introducing an artificial
token. IMO, a it would be more helpful to pass along our use cases to
the policy spec.
Subbu
Richard Jacob wrote:
> Hi Mike et. al,
>
> I'm not proposing that the standard solution would have two different
> ports. I find it cumbersome and errorprone, too. In addition this
solution
> would need some form of WSDL annotation to be able to tell by the
Consumer
> which port to choose.
> I was rather trying to express what I see in some implementations of the
WS
> stack (on of them is the IBM one, the other one might be AXIS with
WSS4J).
>
> I agree that a username token with a well known value like wsrp:anonymous
> might be really the best approach (this would allow for a signature of
that
> token to verify trust in the token asserter).
> The producer should then handle this accordingly.
>
> However I started to dig in into this and at least in our case we can
> specify a J2EE JAAS login config to handle a token. But as far as I know
> once you do that the user must be authenticated in some form, i.e. in the
> J2EE server this user would then be in the group "All authenticated
users"
> as the minimum.
> I think there is no way to not attach a security context at al, i.e.
really
> asserting the anonymous user.
> While one could threat it within the portal (recognize the anonyous user
ID
> and take away right for that principal), this might impose problems since
> backend systems for example might make their decisions based on the
> security context (which can't be empty and might contain the information
> "all authenitcated users").
>
> I'll contact my security guys here...
>
> 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
>
>
>
> Michael Freedman
> <michael.freedman
> @oracle.com>
To
> Subbu Allamaraju <subbu@bea.com>
> 08/15/06 10:40 PM
cc
> Richard Jacob/Germany/IBM@IBMDE,
> wsrp-interop@lists.oasis-open.org
>
Subject
> Re: [wsrp-interop] Re: [wsrp]
> Anonymous User
>
>
>
>
>
>
>
>
>
>
> But I am asking for whether we want to define any interoperable
> (default) convention in the meantime. Right now it seems the advice is
> for each consumer/producer vender to go it alone and define what suits
> them best as a default (though I am sure we encourage consumers to make
> this configurable). Why is this the preferred interop guidance?
>
> In any case, for those consumer vendors out there, how flexible are you
> currently? Can you be configured to deal with a producer that:
> 1) excludes the Username Token (and doesn't support an additional portl)
> 2) excludes the Username Token (and does support an additional port)
> 3) expects/sends a producer defined token to represent the anonymous user
> -Mike-
>
> Subbu Allamaraju wrote:
>
>> Michael Freedman wrote:
>>
>>> 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?
>>
>> AFAIK, the upcoming SecurityPolicy spec (under OASIS WS-SX TC
>> http://www.oasis-open.org/apps/org/workgroup/ws-sx/) will have some
>> provision in the policy language for multiple policy alternatives
>> against the same web service. Of course, the devil will be in the
>> details, but this should give consumers/producers an ability to choose
>> between different kinds of tokens or even lack of a token (for the
>> anonymous case). Given this, I don't think it is appropriate for the
>> WSRP TC to manufacture a token.
>>
>> Since there is an OASIS TC now to discuss security policy issues, we
>> should officially communicate our use cases to WS-SX TC.
>>
>> Subbu
>>
>>> 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.org
>>>>
>>>>
>>>>> Subject
>>>>> 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.
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>
>
_______________________________________________________________________
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]