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

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

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