[jboss-dev] pluggable auth-method

Sergey Beryozkin sberyozk at redhat.com
Thu Jul 15 11:23:46 EDT 2010


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" <Anil.Saldhana at redhat.com> 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"<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


More information about the jboss-development mailing list