[jboss-dev] pluggable auth-method
Sergey Beryozkin
sberyozk at redhat.com
Thu Aug 26 07:41:49 EDT 2010
Well it was rather me incapable of ensuring the Valve had all the setters and getters for the (attribute) properties,
this is the only thing I changed today and apparently it made the trick
sorry for a noise, Sergey
----- "Sergey Beryozkin" <sberyozk at redhat.com> wrote:
> JBossWeb, or may be rather the Tomcat integration code (in JBossAs
> trunk/tomcat) does not seem to be capable
> of injecting custom attributes into Valves instances.
>
> Example, I have a context configuration with a Valve element having
> few attributes meant to customize the way this Valve will work,
> but I never see the properties injected.
>
> There's the code there which is supposed to inject the attribute
> values, ex, in TomcatService :
>
> if (metaData.getAttributes() != null) {
> Iterator<QName> names =
> metaData.getAttributes().keySet().iterator();
> while (names.hasNext()) {
> QName name = names.next();
> String value = (String)
> metaData.getAttributes().get(name);
> // FIXME: This should be done by XB
> value = StringPropertyReplacer.replaceProperties(value);
> IntrospectionUtils.setProperty(instance,
> name.getLocalPart(), value);
> }
> }
>
> As it happens a metaData instance has no attributes despite them being
> available in the configuration, ex :
>
> <Context>
> <Valve className="someClass" a="b"/>
> </Context>
>
> but the className is actually retrieved and is not null.
>
> This makes me think the unmarshalling does not work earlier on in
> JBossContextConfig.processContextConfig :
>
> SchemaBinding schema = JBossXBBuilder.build(ContextMetaData.class);
> Unmarshaller u = UnmarshallerFactory.newInstance().newUnmarshaller();
> ....
> contextMetaData = ContextMetaData.class.cast(u.unmarshal(is,
> schema));
>
>
> Am I missing something ? Has anyone written a custom Valve with
> attributes being provided in the config, running on top of JBossWeb
> before ?
>
> thanks, Sergey
>
> ----- "Anil Saldhana" <Anil.Saldhana at redhat.com> wrote:
>
> > 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"<sberyozk at redhat.com> 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"<brian.stansberry at redhat.com> wrote:
> > >>
> > >>> JBoss AS uses JBoss Web (derived from Tomcat), not Tomcat
> itself.
> > >>>
> > >>>
> > >>
> >
> https://repository.jboss.org/nexus/content/repositories/public-jboss/org/jboss/web/jbossweb/3.0.0-beta-6/
> > >>> 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"<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
> _______________________________________________
> 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