[jboss-dev] pluggable auth-method
Sergey Beryozkin
sberyozk at redhat.com
Wed Aug 25 12:24:24 EDT 2010
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
More information about the jboss-development
mailing list