We don't have a special error code for reasons of standards compliance. We
use the E_invalidKeyPassed for Inquiry operations to UDDI entries to which user
doesn't have access and E_UserMisMatch for Publish operations to which user has
inquiry rights but is not the owner.
Pat
>>> Anne Thomas Manes <anne@manes.net> 02/04/03
03:50PM >>>
Systinet WASP UDDI supports entity-level access control. They added the
E_invalidPermission error code for this purpose. Novell Nsure UDDI also supports
entity-level access control. I don't know if they added an error
code.
Anne
Dave,
The concept of fine
grained read access control is not fully developed in the UDDI V3
specification. The scenario you describe requires an error code at the
granularity of datum, whereas the error codes provided focus on the policies
which describe read access at the granularity of the entire data set via the
inquiry API set.
I'll raise the
issue of a lack of error code for this scenario in the technical committee,
but it is worth considering that the impact of fine grained access has on the
inquiry results from find_xx APIs and the impact on resolving references
within the data (such as a tModel referenced by a binding). As Sam
mentioned it may be appropriate to use invalidKeyPassed in the get_xx case.
The find_xx APIs, it may be appropriate to exclude the result from the
list.
In this particular case,
does the underlying authorization model and policy for read access provide
some useful information for each matching datum that is not readable given the
role of the user?
Andrew
Hately IBM Austin UDDI Development, Emerging Technologies
Dave Schneider
<dschneider@e2open.com>
02/04/2003 09:30 AM
|
To
| "'John Colgrave'"
<colgrave@hursley.ibm.com>
|
cc
| uddi-dev@lists.oasis-open.org
|
Subject
| RE: [uddi-dev] Error
code for authz failures? |
|
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 To:
'Andrew
Hately' Cc:
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
|