Return-Path: X-Original-To: apmail-felix-dev-archive@www.apache.org Delivered-To: apmail-felix-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 52238DA4E for ; Thu, 27 Sep 2012 23:10:54 +0000 (UTC) Received: (qmail 78201 invoked by uid 500); 27 Sep 2012 23:10:54 -0000 Delivered-To: apmail-felix-dev-archive@felix.apache.org Received: (qmail 78007 invoked by uid 500); 27 Sep 2012 23:10:53 -0000 Mailing-List: contact dev-help@felix.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@felix.apache.org Delivered-To: mailing list dev@felix.apache.org Received: (qmail 77980 invoked by uid 99); 27 Sep 2012 23:10:53 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 27 Sep 2012 23:10:53 +0000 X-ASF-Spam-Status: No, hits=2.9 required=5.0 tests=HTML_MESSAGE,SPF_HELO_PASS,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [216.86.168.182] (HELO mxout-07.mxes.net) (216.86.168.182) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 27 Sep 2012 23:10:27 +0000 Received: from mail-ie0-f177.google.com (unknown [209.85.223.177]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 154EB22E257 for ; Thu, 27 Sep 2012 19:10:05 -0400 (EDT) Received: by ieje14 with SMTP id e14so7570745iej.22 for ; Thu, 27 Sep 2012 16:10:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:content-type:x-gm-message-state; bh=MPmLgJgD+rLo2UNkUdH+ReYd4mKm+UrswMtZK063Ihc=; b=VPmnxqVOlsdDQrxWciqywA2eAWAj0BIJ55Hg0WTW+JoVc1LyvZvPY4giGKBBBVrLnK 5PDqS+mMvEu3hvb8E0ecqvivW8wjEen47ohe3fGwLicPFHuVmrEQHher5YC0zHQiV0hO qOhk0n363e/zY1fZwYM9tIU4SW8ISlstzyUOLbEiGjuKGR6gWY9hCuE1MDOrzySskHJr SwSuuEhvHTTF29vK+px32ujrrmNVRtySAHLdPvJneDqyAyhC3M821u4LXZt239yhqeVS yijJ+ddZTYtw00gdRafVh85Eh9tbMzhOpj31csXaWIFssBIefugdtQWIwulHyKhQFTOS rnrg== MIME-Version: 1.0 Received: by 10.42.62.143 with SMTP id y15mr4191809ich.38.1348787405484; Thu, 27 Sep 2012 16:10:05 -0700 (PDT) Received: by 10.64.53.8 with HTTP; Thu, 27 Sep 2012 16:10:05 -0700 (PDT) X-Originating-IP: [91.137.97.21] In-Reply-To: References: Date: Fri, 28 Sep 2012 01:10:05 +0200 Message-ID: Subject: Re: Bundle to simplify JAAS usage in OSGi From: =?ISO-8859-1?Q?Reto_Bachmann=2DGm=FCr?= To: dev@felix.apache.org Content-Type: multipart/alternative; boundary=20cf30223c912e73c504cab70a93 X-Gm-Message-State: ALoCoQnm3O7UsmvWwRBfo6ZJP3LyTZUdZpzGegQd4JnKRDkMsXtSh0DcsTO0U4ivXk5L/8k4X2+B X-Virus-Checked: Checked by ClamAV on apache.org --20cf30223c912e73c504cab70a93 Content-Type: text/plain; charset=ISO-8859-1 Hi Chetan Recently we have added security to Stanbol so that it can be run with a security manager in place. Regarding authentication of HTTP clients for now the providers must implement our own service interface [1]. The authentication providers authenticate a user before subsequent processing of the request is executed as the authenticated subject. Could you help me understand what using your bundle would imply. Is this a regular bundle that can just be added to any OSGi application ore are some special tweaks needed starting/configuring the platform? Cheers, Reto 1. http://svn.apache.org/viewvc/stanbol/trunk/commons/security/src/main/java/org/apache/stanbol/commons/security/auth/AuthenticationMethod.java?view=markup On Wed, Sep 26, 2012 at 3:56 PM, Chetan Mehrotra wrote: > I have been working on a poc to simplify usage if JAAS with Sling and > Jackrabbit. Using of JAAS within OSGi is often tricky because of > classloading issues. There has been some work done around this > > 1. JAAS support in Apache Karaf > 2. Proposal by Stefan Vladov in the presentation [1] given by him at > OSGi Community Event 2011 > > Following the proposal at #2 and borrowing some ideas from Apache > Karaf I implemented a bundle which simplifies usage of JAAS within > OSGi env. It supports following features > > 1. It can work both in Standalone and AppServer deployments i.e. in > those environment where global JAAS configuration might be used by > other applications and our usage of JAAS should not affect them > 2. It enables usage of OSGi Configuration support to dynamically > configure the login modules. > 3. It allows LoginModule instances to be created via factories > registered in OSGi Service Registry > 4. It does not require the client to depend on any OSGi API > 5. It works well with the dynamic nature of the OSGi env > 6. Implementation depends only on Core OSGi API and ConfigAdmin > > Complete details are provided at [2] > > Kindly have a look at it and provide feedback!! > > Chetan Mehrotra > > [1] > http://www.slideshare.net/mfrancis/common-security-services-consolidation-patterns-for-legacy-components-stefan-vladov > [2] https://github.com/chetanmeh/c/wiki/JAAS-in-OSGi > --20cf30223c912e73c504cab70a93--