[jboss-dev] pluggable auth-method

Thu Jul 15 12:50:26 EDT 2010

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
>> _______________________________________________
>> jboss-development mailing list
>> jboss-development at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-development
> _______________________________________________
> jboss-development mailing list
> jboss-development at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development

-- 
Brian Stansberry
Lead, AS Clustering
JBoss by Red Hat