JBoss AS uses JBoss Web (derived from Tomcat), not Tomcat itself. https://repository.jboss.org/nexus/content/repositories/public-jboss/org/... 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&quot;&lt;Anil.Saldhana(a)redhat.com&gt; 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&quot;&lt;Anil.Saldhana(a)redhat.com&gt; 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(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jboss-development > _______________________________________________ > jboss-development mailing list > jboss-development(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-development -- Brian Stansberry Lead, AS Clustering JBoss by Red Hat _______________________________________________ jboss-development mailing list jboss-development(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development