OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

uddi-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


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



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




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC