RE: [uddi-dev] Error code for authz failures?

[Dave Schneider <dschneider@e2open.com>]

Sam,

Thanks for the explanation.  I think I finally see now the approach that's
been taken.

Dave

______________________________________
Dave Schneider  ---  dschneider@e2open.com


-----Original Message-----
From: Wai-Kwong Sam LEE [mailto:Sam.Lee@oracle.com]
Sent: Tuesday, February 04, 2003 11:50 AM
To: Dave Schneider
Cc: 'John Colgrave'; uddi-dev@lists.oasis-open.org
Subject: Re: [uddi-dev] Error code for authz failures?


I'll try to elaborate what John Colgrave has pointed out.

UDDI specification itself does have a simple implicit authorization model:
a client can essentially update the entities that the client creates;
a client can also create any entities (recall that save_service and 
save_binding is essentially updating the businessEntity so they don't 
count as creation).

If a client violates the above authorization model, the client will 
receive E_userMismatch error.

The scenario you raised has an extended authorization model, hence the 
error message used is not spelt out in the specification. The actual 
behavior depends on the details of what you need to achieve with such an 
extended authorization model.

For example, if you do not want the client to know the existence of the 
entity, it'd make sense to return E_invalidKeyPassed. If you do want to 
let the client that the requested entity exists but the client cannot 
access it due to authorization policy, you might return E_userMismatch.



- sam

Dave Schneider wrote:
> John,
>  
> I knew I shouldn't have used that example. :-)  As I mentioned, the 
> example could be for a read operation as well, where the implementation 
> provides fine-grained access control on the get_* operations as well as 
> for publishing.  So let's change the example to one where the user tried 
> a get_bindingDetail call and the server determined the user wasn't 
> allowed to read the data.
>  
> Thanks,
> Dave
> 
> ______________________________________
> Dave Schneider  ---  dschneider@e2open.com
> 
> -----Original Message-----
> *From:* John Colgrave [mailto:colgrave@hursley.ibm.com]
> *Sent:* Tuesday, February 04, 2003 9:24 AM
> *To:* Dave Schneider
> *Cc:* uddi-dev@lists.oasis-open.org
> *Subject:* Re: [uddi-dev] Error code for authz failures?
> 
> Dave,
>  
> In the save_binding scenario you describe I would expect a registry to 
> return E_userMismatch.
>  
> John Colgrave
> IBM
> 
>     ----- Original Message -----
>     *From:* Dave Schneider <mailto:dschneider@e2open.com>
>     *To:* 'Andrew Hately' <mailto:hately@us.ibm.com>
>     *Cc:* uddi-dev@lists.oasis-open.org
>     <mailto:uddi-dev@lists.oasis-open.org>
>     *Sent:* Tuesday, February 04, 2003 2:35 PM
>     *Subject:* RE: [uddi-dev] Error code for authz failures?
> 
>     Andrew,
>      
>     Maybe I'm just not clear on what an "invalid" token would be.  The
>     scenario I describe is one where the user has obtained a perfectly
>     valid authInfo token that is not yet expired.  It's just that due to
>     the authorization policies in place, the user is not allowed to
>     read/publish/modify the data in question.
>      
>     While this could apply equally well to a get_* operation, an example
>     might be that someone attempts to use save_binding to modify an
>     existing BindingTemplate.  But since the user either isn't the owner
>     of the object, or isn't in an access group that has been granted
>     modify access, the server determines the user isn't allowed to
>     modify that BindingTemplate.  In this case, are you saying the
>     appropriate response is E_authTokenRequired despite the fact that
>     the caller provided an unexpired and valid token?
>      
>     Thanks,
>     Dave
>      
> 
>     ______________________________________
>     Dave Schneider  ---  dschneider@e2open.com
> 
>     -----Original Message-----
>     *From:* Andrew Hately [mailto:hately@us.ibm.com]
>     *Sent:* Monday, February 03, 2003 10:44 PM
>     *To:* Dave Schneider
>     *Cc:* uddi-dev@lists.oasis-open.org
>     *Subject:* Re: [uddi-dev] Error code for authz failures?
> 
> 
>     Dave,
> 
>     For registries using the UDDI security API set, the following should
>     be appropriate:
> 
>     *E_authTokenRequired*: (10120) Signifies that an authentication
>     token is missing or is invalid for an API call that requires
>     authentication.
> 
>     As other mechanisms are outside the scope of the UDDI specification,
>     authorization errors relating to those mechanisms should be covered
>     outside the UDDI specification.
> 
>     If there is a need to provide a more granular error within the UDDI
>     specification, please provide more information or the use case for
>     further detailing authorization errors.
> 
>     Andrew Hately
>     IBM Austin
>     UDDI Development, Emerging Technologies
> 
> 
> 
>     *Dave Schneider <dschneider@e2open.com>*
> 
>     02/03/2003 06:18 PM
> 
>     To
>     "'uddi-dev@lists.oasis-open.org'" <uddi-dev@lists.oasis-open.org>
>     cc
>     Subject
>     [uddi-dev] Error code for authz failures?
> 
> 
> 
> 
> 
> 
>     Given that every API in v3 takes an optional authInfo parameter, I was
>     surprised I didn't find an error code such as E_accessDenied or
>     E_authzFailed in Chapter 12 of the v3 spec.  The only thing seemed
>     close was
>     E_requestDenied, but the description implies its use is only for
>     requesting
>     subscription renewals.  Any idea what the appropriate error code
>     should be
>     when the server decides the caller isn't authorized to do what's being
>     requested?
> 
>     Thanks,
>     Dave
> 
>     ______________________________________
>     Dave Schneider  ---  dschneider@e2open.com
> 
>