In the case of rogue requestor being the client, it does not have visibility into what is included in the permission ticket ( ticket is a reference returned by rs to be presented at as). It may dos Rs with requests, which rs may implement a solution like rate limiting (not described in uma).
The as api for rs is protected via an oauth2 token (PAT) which rs must present for permission registration (as well as for other functions). This Pat allows as to map es’s request to a particular Ro. Rs can only ask for permissions for the resources and scopes it already registered with the As. Hope I was able to clarify. Thanks, —Cigdem On Wednesday, October 25, 2017, Jim Schaad <[email protected]> wrote: > So you would be doing based on something like the address of the requestor > or the content of the request. I would complete understand the first > half. Is there any way to prevent a rouge requestor from asking for > information – or are you just relying on a closed system? > > > > *From:* Cigdem Sengul [mailto:[email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>] > *Sent:* Wednesday, October 25, 2017 2:19 PM > *To:* Jim Schaad <[email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>> > *Cc:* Ludwig Seitz <[email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>>; [email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');> > *Subject:* Re: [Ace] Question about the response to an unauthorized > request > > > > UMA assumes that resource server knows “which authorization server to > approach for the permission ticket and on which resource owner's behalf” > deriving “the necessary information using cues provided by the structure of > the API where the resource request was made, rather than by an access > token. “ > > On Wednesday, October 25, 2017, Jim Schaad <[email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>> wrote: > > How does the RS make an informed decision about who the client is given > that it is a tokenless access request? > > > > > > > > *From:* Ace [mailto:[email protected]] *On Behalf Of *Cigdem Sengul > *Sent:* Wednesday, October 25, 2017 7:28 AM > *To:* Ludwig Seitz <[email protected]> > *Cc:* [email protected] > *Subject:* Re: [Ace] Question about the response to an unauthorized > request > > > > Hello, > > > > To bring a different view, I wanted to mention Kantara UMA (User Managed > Access) approach to this problem. (I participated in the UMA v2.0 > development this year, so had the chance to be more familiar with the new > drafts.) > > > > In UMA, the resource server must respond to a client's tokenless > (unauthorized) access attempt by obtaining a permission ticket from the > authorization server. > > If RS is able to obtain a permission ticket from the AS, RS returns this > ticket to the client also with the AS uri to aid AS discovery. > > > > UMA handles resources (resource sets, permissions etc.) differently but > the permission requests (from RS to AS) can be considered as signaling to > the AS what audience/scope RS expects. > > > > In ACE, there are limitations of course - i.e., RS may not always reach AS > etc. Nevertheless, it may be useful to think how other groups approach > similar problems. > > > > Best, > > --Cigdem > > > > > > On Mon, Oct 23, 2017 at 2:38 PM, Ludwig Seitz <[email protected]> wrote: > > Hello ACE, > > Jim Schaad has brought up an interesting question [1] on > draft-ietf-ace-oauth-authz [2]: > > Currently when a client makes an unauthorized request to a resource > server, it gets back the address of the authorization server and optionally > a nonce (to prevent replay attacks). > > Jim is suggesting to add hints to the audience and scope the resource > server expects for accessing this resource. > > I'm not sure whether that would not reveal too much information to a > potential attacker. > > What does the group think of this issue? > > /Ludwig > > > [1] https://github.com/ace-wg/ace-oauth/issues/124 > [2] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-08# > section-5.1.2 > -- > Ludwig Seitz, PhD > Security Lab, RISE SICS > Phone +46(0)70-349 92 51 > > _______________________________________________ > Ace mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ace > > > >
_______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
