Return-Path: X-Original-To: apmail-httpd-modules-dev-archive@minotaur.apache.org Delivered-To: apmail-httpd-modules-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 682418AF6 for ; Thu, 15 Sep 2011 16:03:18 +0000 (UTC) Received: (qmail 90802 invoked by uid 500); 15 Sep 2011 16:03:17 -0000 Delivered-To: apmail-httpd-modules-dev-archive@httpd.apache.org Received: (qmail 90772 invoked by uid 500); 15 Sep 2011 16:03:17 -0000 Mailing-List: contact modules-dev-help@httpd.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: modules-dev@httpd.apache.org Delivered-To: mailing list modules-dev@httpd.apache.org Received: (qmail 90764 invoked by uid 99); 15 Sep 2011 16:03:17 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 15 Sep 2011 16:03:17 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [66.111.4.27] (HELO out3.smtp.messagingengine.com) (66.111.4.27) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 15 Sep 2011 16:03:12 +0000 Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id DF7CD28973; Thu, 15 Sep 2011 12:02:51 -0400 (EDT) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute6.internal (MEProxy); Thu, 15 Sep 2011 12:02:51 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=lvqTbo1LtQ6aJBhHOkLz86 GJU88=; b=QdvQJslOMVWy0AbQjNwkRRy/OEWZat7TGkjtA79ItZfJdz+u+zvqHA plfrfNXnY7ISLrXoJEHGxM032Qryyrd2ICFztC6mvhhopeOeH0floMuN3pEornHi uaBrWnH36fp441igHfRis9bjWgVoxRaEsq+k5jv2brHP4MvucqsUY= X-Sasl-enc: X4yvMjz1+EOejHyez6P6EeZ0TGSBioQMjHBXyJLHwDty 1316102571 Received: from hitomi.local (unknown [198.111.179.55]) by mail.messagingengine.com (Postfix) with ESMTPSA id 9D571B21716; Thu, 15 Sep 2011 12:02:51 -0400 (EDT) Message-ID: <4E7221AB.1010800@catseye.org> Date: Thu, 15 Sep 2011 12:02:51 -0400 From: Mark Montague User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:5.0) Gecko/20110630 Thunderbird/5.0 MIME-Version: 1.0 To: modules-dev@httpd.apache.org, suneetshah2000@gmail.com Subject: Re: Developing an Authentication Module References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On September 15, 2011 11:41 , Suneet Shah wrote: > In our architecture, authentication and authorization is handled by a set of > web services. I would need to have the apache module make calls to the > service. I was planning on using Axis 2 for this. Are there any issues with > thiat? I have no experience with Axis 2, but an Apache module can certainly utilize external services. For example, mod_auth_kerb makes RPC calls to Kerberos KDCs, and mod_auth_dbd makes queries against SQL databases. > I need to be able to look at request and see if it has a security token. If > it does, then I need to validate it through the service. > > If it does not, then I need to redirect them to an authentication page. > > I thought it would be easier to handle the authentication through our java > application (as we have the rest of the application) or should this part of > the module as well? > > If a person successful authenticates, then the authentication app would > redirect the user to the originally requested url. This sounds very much like the way cosign works. cosign is a web single-sign-on solution that includes an Apache HTTP Server module, mod_cosign. A diagram showing how cosign works is available at http://cosign.sourceforge.net/overview.shtml The actual authentication (prompting for and verifying the user's username and password) is handled by an application written in C which runs as a CGI and is not a part of the mod_cosign module itself. You may also want to study the implementation of other web single-sign-on solutions, including Pubcookie ( http://pubcookie.org/ ) and CAS ( http://www.jasig.org/cas ). CAS may be of particular interest to you because it is written in Java. > This would flow through > the apache web service and mod-proxy to end up at the target location. You may not need mod_proxy unless it is key to your requirements in some way. cosign, for example, simply redirects the user to the target location after verifying the security token (cookie) or authenticating the user and issuing a new security token. -- Mark Montague mark@catseye.org