Re: [jboss-dev] pluggable auth-method

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&quot;&lt;sberyozk(a)redhat.com&gt; 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&quot;&lt;brian.stansberry(a)redhat.com&gt; wrote: >> >>> 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