[jboss-dev] pluggable auth-method

Anil Saldhana Anil.Saldhana at redhat.com
Wed Aug 25 09:52:18 EDT 2010 

  Forget Tomcat4 and 5 public api for AuthenticatorBase.

They changed the API to cater to Servlet3 recently.  Since 
AuthenticatorBase is a
Tomcat interface, they can get away.

Server binding code is always at the risk of internal api changing over 
major versions.

On 08/25/2010 06:17 AM, Sergey Beryozkin wrote:
> Just FYI, org.apache.catalina.authenticator.AuthenticatorBase shipped with
> JBossWeb (3.0-Beta5 and the one used in JBossAS built from the trunk) does not match
> any of the Tomcat AuthenticatorBase classes documented publicly, at least since Tomcat 4.0
>
> JBossWeb expects that an abstract AuthenticatorBase.authenticate method has the following signature :
>
> protected abstract boolean authenticate(org.apache.catalina.connector.Request request,
>                                          javax.servlet.HttpServletResponse response,
>                                          org.apache.catalina.deploy.LoginConfig config) throws IOException;
>
> cheers, Sergey
>
>
> ----- "Sergey Beryozkin"<sberyozk at redhat.com>  wrote:
>
>> Thanks for the links.
>>
>> I checked a JBossAS Tomcat integration module earlier on,
>> at https://svn.jboss.org/repos/jbossas/tomcat
>>
>> and saw the references to jbossweb on forums, but still thought
>> catalina.jar was used somehow internally, thus was curious what the
>> corresponding version was.
>>
>> At the moment I'm just doing a 'provided' scope dependency on catalina
>> 6.0.28, and I'm assuming it will just work in JBoss but I guess the
>> demo will be better off with depending on jbossweb.
>>
>> cheers, Sergey
>>
>> ----- "Brian Stansberry"<brian.stansberry at redhat.com>  wrote:
>>
>>> JBoss AS uses JBoss Web (derived from Tomcat), not Tomcat itself.
>>>
>>>
>> https://repository.jboss.org/nexus/content/repositories/public-jboss/org/jboss/web/jbossweb/3.0.0-beta-6/
>>> is the location of the version currently used in AS trunk.
>>>
>>> https://svn.jboss.org/repos/jbossas/trunk/component-matrix/pom.xml
>> is
>>> the file in the AS trunk that defines that dependency.
>>>
>>> On 7/15/10 10:23 AM, Sergey Beryozkin wrote:
>>>> Well, this is quite obvious, I can quess that one :-)
>>>> Which version of Catalina ? Though probably any in the 5.x range
>>> will do, just not sure if AS 6.0 uses Catalina 6.x or not
>>>> Cheers, Sergey
>>>>
>>>> ----- "Anil Saldhana"<Anil.Saldhana at redhat.com>   wrote:
>>>>
>>>>> Sergey,
>>>>>      extend Tomcat AuthenticatorBase class for your authenticator.
>>> It
>>>>> should have available in the catalina jar.
>>>>>
>>>>> Cheers.
>>>>>
>>>>> On 07/15/2010 09:20 AM, Sergey Beryozkin wrote:
>>>>>> Hi Anil
>>>>>>
>>>>>>
>>>>>> ----- "Anil Saldhana"<Anil.Saldhana at redhat.com>    wrote:
>>>>>>
>>>>>>
>>>>>>> The login modules happen late in the container security
>> sequence
>>>>> and
>>>>>>> have limited access to the network message etc.  They can only
>>> say
>>>>>>> yes/no to authentication.  But they cannot do some of the
>>> redirects
>>>>> or
>>>>>>> other extra steps that are needed in mechanisms outside of the
>>>>> servlet
>>>>>>> spec mechanisms (form, client-cert, basic,digest).   SAML,
>>>>>>> OpenID/OAuth
>>>>>>> etc may need access to the network message (http message) and
>>> may
>>>>> have
>>>>>>> to redirect the request to an external identity provider.  In
>>>>> these
>>>>>>> situations, you do container integration (in the case of
>> tomcat,
>>> it
>>>>> is
>>>>>>> via authenticators).
>>>>>>>
>>>>>>> Ideally, you should be doing JSR-196 which will provide you the
>>>>>>> pluggable server authentication modules and can stack modules
>>> just
>>>>> as
>>>>>>> you do with login modules.
>>>>>>>
>>>>>>> We have support for JSR-196 in AS6 which needs to be taken
>>> further
>>>>>>> before EE6 certification.
>>>>>>> http://anil-identity.blogspot.com/search/label/jsr-196
>>>>>>>
>>>>>>>
>>>>>> thanks for all the info, I will experiment with Athenticators,
>> no
>>>>> redirection will be needed in cases where they should
>>>>>> enforce that a given OAuth consumer is a valid one, but I'd like
>>> to
>>>>> try them too...
>>>>>> How to figure out which catalina/tomcat dependency should be
>> used
>>>>> for writing a custom Authenticator to be used in JBossAS 6.0
>>>>> deployments ?
>>>>>> thanks, Sergey
>>>>>>
>>>>>>
>>>>>>
>>>>>>> On 07/14/2010 11:17 AM, Sergey Beryozkin wrote:
>>>>>>>
>>>>>>>> Hi
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> For OAuth there are a few issues:
>>>>>>>>>
>>>>>>>>> 1. It has specific headers.
>>>>>>>>> 2. You create "secrets" on the fly which are used to
>>>>> authenticate
>>>>>>> and
>>>>>>>
>>>>>>>>> authorize requests.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>> Regarding 2: This is just one approach which the RestEasy
>>>>>>>>
>>>>>>> oauth-push-messaging takes, but one can imagine
>>>>>>>
>>>>>>>> the administrator registering the OAuth consumers representing
>>>>> say
>>>>>>> messaging services in advance.
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> Maybe its best to first iterate on an Authenticator, then
>> move
>>>>>>> logic
>>>>>>>
>>>>>>>>> up
>>>>>>>>> the stack once you get a prototype going?  I don't know how
>>>>> Sergey
>>>>>>>>> likes
>>>>>>>>> to work :)
>>>>>>>>>
>>>>>>>>>
>>>>>>>> Well, my own problem so far is that I doubt the necessity of
>>>>>>>>
>>>>>>> introducing a role-based
>>>>>>>
>>>>>>>> control access in a push-messaging case given the way the
>>> current
>>>>>>> solution works.
>>>>>>>
>>>>>>>> Specifically, a subscriber needs to grant the messaging
>> service
>>> a
>>>>>>> permission to access a destination URI using a (domain)
>>>>> admin-level
>>>>>>> invocation on the message receiver; in other words the
>>> subscriber
>>>>> can
>>>>>>> not just tell the messaging service to push to some arbitrary
>>>>> server,
>>>>>>> the subscriber needs to control that specific URI space on that
>>>>>>> server; it is really the subscriber's space in the end of the
>>> day.
>>>>>>>> So it is an admin-level decision which is enforced by the
>> OAuth
>>>>>>> filter anyway - by authenticating (by ensuring current OAuth
>>>>> client_id
>>>>>>> matches the records and checking the signature the secret) and
>>>>>>> validating that the request URI matches the one specified by
>> the
>>>>> admin
>>>>>>> (subscriber) at the previous step.
>>>>>>>
>>>>>>>> Thus it is not obvious to me why it is worth introducing
>>> another
>>>>>>> authorization layer, at least given the way the push-messaging
>>>>> demo
>>>>>>> works at the moment. And when I'm in doubt I'm really working
>>> very
>>>>>>> slowly, sorry, probably not a good thing to say publicly :-)
>>>>>>>
>>>>>>>> Where I can see the login modules may be introduced is when we
>>>>> have
>>>>>>> OAuth consumers registered well in advance and say the
>>>>> administrator
>>>>>>> allocates roles to various consumers using nice UI and then we
>>> have
>>>>> a
>>>>>>> case where some consumers may access one (resource) service
>>> method
>>>>> and
>>>>>>> some other consumers can access some other method only. It is
>>> not
>>>>> the
>>>>>>> case with the push-messaging demo though.
>>>>>>>
>>>>>>>> cheers, Sergey
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> Chris Bredesen wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Yes.
>>>>>>>>>>
>>>>>>>>>> Authenticator is a Catalina/Web construct that delegates to
>> a
>>>>>>> Realm
>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> (Catalina construct) that, in JBAS is backed by LoginModules
>>>>>>>>>>
>>>>>>> (JAAS
>>>>>>>
>>>>>>>>>> constructs, JBoss implementations).
>>>>>>>>>>
>>>>>>>>>> JAAS LoginModules are constrained by their own API which
>>> means
>>>>>>> they
>>>>>>>
>>>>>>>>>>
>>>>>>>>> get
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> access to only certain callbacks (username, password, etc)
>>> and
>>>>>>> have
>>>>>>>
>>>>>>>>>>
>>>>>>>>> no
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> knowledge of the Servlet API.  You can do authentication in
>>> an
>>>>>>>>>> Authenticator but that's not portable to other
>> non-Tomcat/JBW
>>>>>>>>>> environments.  The naming is a bit confusing IMO.  It made
>>>>> sense
>>>>>>> for
>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Tomcat but adds confusion in JBAS.
>>>>>>>>>>
>>>>>>>>>> You don't need to worry about writing an Authenticator
>> unless
>>>>> you
>>>>>>>>>>
>>>>>>>>> need
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> access to something that you don't already get from the
>>>>> existing
>>>>>>>>>> Authenticators, such as cookies, etc.
>>>>>>>>>>
>>>>>>>>>> -CB
>>>>>>>>>>
>>>>>>>>>> On 07/14/2010 10:53 AM, Bill Burke wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> Just guessing,
>>>>>>>>>>>
>>>>>>>>>>> Isn't the login module responsible for the actual
>>>>> authentication
>>>>>>>>>>>
>>>>>>>>> and
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>> authorization?  Tomcat authenticator is just responsible
>> for
>>>>>>>>>>>
>>>>>>>>> extracting
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>> header info?
>>>>>>>>>>>
>>>>>>>>>>> Sergey Beryozkin wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> Hi
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> You can achieve by writing a tomcat authenticator and
>>>>> putting
>>>>>>> it
>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>> in
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>> WEB-INF/context.xml (JBAS) or META-INF/context.xml
>>> (tomcat).
>>>>>>>>>>>>> The auth-name is a string defined in the servlet spec.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>> thanks for the tip.
>>>>>>>>>>>>
>>>>>>>>>>>> What is the difference between writing a custom Tomcat
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>> authenticator and a custom LoginModule, example,
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>
>> org.picketlink.identity.federation.bindings.jboss.auth.SAML2STSLoginModule
>>>>>>>>> ?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>> My understanding is that having custom login modules :
>>>>>>>>>>>>       - makes it easy to stack together different modules,
>>> as
>>>>>>> shown
>>>>>>>
>>>>>>>>>>>>
>>>>>>>>> for ex at [1]
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>       - but requires the explicit loading of (JBoss
>>> Security)
>>>>>>>>>>>>
>>>>>>>>> AuthenticationManager (at least when services are POJOs)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>> cheers, Sergey
>>>>>>>>>>>>
>>>>>>>>>>>> [1]
>>>>>>>>>>>>
>>>>>>>>>>>>
>>> http://community.jboss.org/wiki/SAMLEJBIntegrationwithPicketLinkSTS
>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> On 07/13/2010 11:35 AM, Bill Burke wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Remy, Anil,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> (I'm cc'ing jboss-dev for archive purposes)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Sergey , a new web services/resteasy hire, has done some
>>>>>>>>>>>>>>
>>>>>>> great
>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>> work
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>>> around OAuth lately.  I'm interested in taking his stuff
>>> to
>>>>>>> the
>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>> next
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>>> level and make it consumable in a way JBoss AS users are
>>>>> used
>>>>>>>>>>>>>>
>>>>>>>>> to
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>>> configuring security.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Specifically, I'm interested in defining a OAuth
>>>>>>>>>>>>>> login-config/auth-method within web.xml i.e.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> <login-config>
>>>>>>>>>>>>>> <auth-name>OAuth</auth-name>
>>>>>>>>>>>>>> <realm-name>...</realm-name>
>>>>>>>>>>>>>> </login-config>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This would be an initial step, eventually I'd like to be
>>>>> able
>>>>>>>>>>>>>>
>>>>>>>>> to
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>>> configure a web app to support multiple authentication
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>> mechanisms,
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>> so
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> that one URL could support both OAuth and traditional
>>>>>>>>>>>>>>
>>>>>>> clients.
>>>>>>>
>>>>>>>>>>>>>> Is JSR 196 the way to do this?  Do we support in AS6?
>> Is
>>>>>>> there
>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>> doco
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>>> someplace?  (I couldn't find with a search).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Bill

More information about the jboss-development mailing list