Re: [jboss-dev] pluggable auth-method

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