[jboss-dev] pluggable auth-method

Thu Jul 15 10:20:42 EDT 2010

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