[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrp-interop] Re: [wsrp] Anonymous User
Richard Jacob wrote: > 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. To me that's an artificial token :) > 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. You are right. That's my concern too. Even getting a special user created is not an easy battle to fight with the security lords. > 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). I agree. However, we usually let our users decide how to extend/tweak the system. This seems like a special case requiring a special interpretation. Given that we have kept the spec clean of any security discussions so far, why introduce a special token in the WSRP spec now? Subbu > > 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. > > _______________________________________________________________________ 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]