Return-Path: X-Original-To: apmail-cxf-users-archive@www.apache.org Delivered-To: apmail-cxf-users-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 99ECF70FA for ; Wed, 9 Nov 2011 02:17:06 +0000 (UTC) Received: (qmail 70389 invoked by uid 500); 9 Nov 2011 02:17:05 -0000 Delivered-To: apmail-cxf-users-archive@cxf.apache.org Received: (qmail 70324 invoked by uid 500); 9 Nov 2011 02:17:05 -0000 Mailing-List: contact users-help@cxf.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@cxf.apache.org Delivered-To: mailing list users@cxf.apache.org Received: (qmail 70316 invoked by uid 99); 9 Nov 2011 02:17:05 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 09 Nov 2011 02:17:05 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [209.85.212.41] (HELO mail-vw0-f41.google.com) (209.85.212.41) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 09 Nov 2011 02:16:59 +0000 Received: by vws16 with SMTP id 16so1256277vws.0 for ; Tue, 08 Nov 2011 18:16:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.27.72 with SMTP id r8mr733896vdg.71.1320804998608; Tue, 08 Nov 2011 18:16:38 -0800 (PST) Received: by 10.52.112.129 with HTTP; Tue, 8 Nov 2011 18:16:38 -0800 (PST) Date: Tue, 8 Nov 2011 18:16:38 -0800 Message-ID: Subject: 2.5 and OAuth From: Jeff Wang To: users@cxf.apache.org Content-Type: text/plain; charset=ISO-8859-1 X-Virus-Checked: Checked by ClamAV on apache.org With great anticipation, I am looking through the OAuth 1.0 implementation in CXF. I have some questions: In AuthorizationRequestService 1) This is just authorization, right? So we actually need to have secured the (in the example) /forms/oauthAuthorize.jsp so that before they go there, they are authenticated as a user of myapp? In Protecting resources with OAuth filters, Bullet point 2, "It will check if Client and AccessToken have a "uris" property set and if yes then it will validate the current request URI against it." 1) the list of URIs with the client is the client's app, right? (www.clientapp.com/clientapp - the javadoc says it could be used to check the callback URL) So the current URI (www.myapp.com/myapp/protectedresource) will always fail? (the Token's scope and uri is fine, because it is set at the time /initiate is called.) 2) Is matching a wildcard match? for example (myapp/user/*/profile myapp/user/{userId}/contacts) if I want to allow a user to see the profile of all their contacts, but not their contacts' contacts. the bullet point 4, "Finally, it will create a SecurityContext using this list of OAuthPermissions and the Client loginName property." 1) Since we're talking about SecurityContext, that means this is Spring Security, right? 2) Since the client (which is a representation of the consumer, right?) is authenticated on behalf of the end user, shouldn't the Authentication object represent the user detail of the end user? 3) Speaking of which, could we configure a custom UserDetailService? 4) Is there a way to protect different endpoints on the same jaxrs:server declaration with different scopes? for example, different scopes for GET /myapp/user/{userId}/profile and GET /myapp/user/{userId}/contact? 5) If I want to make sure that only {userId} have access to their /user/{userId}/super-secret-information, is it possible to make sure that the end-user being authenticated is the same one that is authorized? or do I have to check it in the getSuperSecretInformation method via the SecurityContextHolder? Thanks, and I look forward to using this new feature! Jeff