VFS3 (in AS trunk) - Non .jar file handling
by Jaikiran Pai
I see a new behaviour with VFS3 in JBoss AS. Earlier in AS-5/6 (with
VFS2) and AS-4 (without any VFS), to try out some quick fixes, i used to
rename existing jar files to end with .bak name and replace them with
the new patched jar file. So for example, if i had a fix in
jboss-ejb3-core.jar, i would:
1) Rename the JBOSS_HOME/common/lib/jboss-ejb3-core.jar to
JBOSS_HOME/common/lib/jboss-ejb3-core.jar.orig.bak
2) Place a patched jboss-ejb3-core.jar in JBOSS_HOME/common/lib
3) Restart the server
The server would then pickup the new patched jar file and ignore the
.bak file. After testing the fix, i would then revert back to the
original jar file by renaming it back to its original name.
However, with the recent upgrade to VFS3 in AS trunk, i notice that even
the .bak is used for classloading (following is the output from
-verbose:class JVM argument):
[Loaded org.jboss.ejb3.EJBContainer from
file:/NotBackedUp/jpai/business/jboss/wc/jbossas/trunk/build/target/jboss-6.0.0-SNAPSHOT/common/lib/jboss-ejb3-core.jar.orig.bak/]
Looks like VFS3 picks up this non .jar suffix file for classloading. Is
this expected? Shouldn't it be looking for only .jar files (atleast in
this context)?
regards,
-Jaikiran
14 years
VHosts in AS 6 and naming
by Remy Maucherat
Hi,
In AS 5 (I believe), we added the capability to deploy a webapp to
multiple vhosts. While nice in practice, this causes the need for a
hack where one webapp can be deployed multiple times to each specified
vhost, as well as automagic vhost creation. I've never liked this
behavior (I think vhost creation should require some administrator
intervention), and this hack is now causing problems with the new
naming. It should be possible to drop this feature to a large extent.
Instead, what could happen is that the list of specified vhosts would
now need to either point to one single existing host (any non existing
vhosts would be added as aliases to that vhost). If nothing exists,
they would be added as aliases to the default host.
This should actually cover most reasonable use cases.
Rémy
14 years, 3 months
as7 test failure
by Dimitris Andreadis
While building AS7 on WinXP, is this expected? (or nobody tests on Windoze)
Failed tests:
testRespawnKilledProcess(org.jboss.as.process.test.RespawnCrashedProcessesTest
Case)
testDelayInRespawningProcessesBeforeGivingUp(org.jboss.as.process.test.Respawn
CrashedProcessesTestCase)
14 years, 3 months
Shelly Leading JBoss AS6 to completion
by Dimitris Andreadis
Hello folks,
As we are marching on both the JBoss AS6 and AS7 development fronts and AS6 is well on its
way for the final stage, the EE6 TCK certification, Jason Greene will be handing over the
Lead for AS6 to Shelly McGowan, so Jason can focus more onto AS7 development.
Shelly is already responsible for the EE6 certification effort and will bring AS6 to
completion in the CR and Final releases to follow, so please coordinate with her and assist
her for the remaining AS6 development/certification work.
Congratulations to Shelly! Let's get those releases out!
/Dimitris
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Dimitris Andreadis
Software Engineering Manager
JBoss Application Server
by Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
http://dandreadis.blogspot.com/
14 years, 3 months
Re: [jboss-dev] pluggable auth-method
by Sergey Beryozkin
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(a)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(a)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(a)redhat.com> wrote:
> >>
> >>> JBoss AS uses JBoss Web (derived from Tomcat), not Tomcat itself.
> >>>
> >>>
> >>
> https://repository.jboss.org/nexus/content/repositories/public-jboss/org/...
> >>> 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(a)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(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
14 years, 3 months
Re: [jboss-dev] pluggable auth-method
by Sergey Beryozkin
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(a)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(a)redhat.com> wrote:
>
> > JBoss AS uses JBoss Web (derived from Tomcat), not Tomcat itself.
> >
> >
> https://repository.jboss.org/nexus/content/repositories/public-jboss/org/...
> >
> > 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(a)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(a)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(a)lists.jboss.org
> > >> https://lists.jboss.org/mailman/listinfo/jboss-development
> > > _______________________________________________
> > > jboss-development mailing list
> > > jboss-development(a)lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/jboss-development
> >
> >
> > --
> > Brian Stansberry
> > Lead, AS Clustering
> > JBoss by Red Hat
> > _______________________________________________
> > jboss-development mailing list
> > jboss-development(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/jboss-development
14 years, 3 months
Building jbossas/trunk
by Shelly McGowan
The recent commit in jbossas/trunk (Revision: 107742) for JBAS-7862 caused a regression in the
jbossas/embedded integration test suite:
specifically, testWs in org.jboss.jbossas.embedded.testsuite.ServerIntegrationTest
This commit was needed to resolve some previous smoke tests failures as well as Blocking issues affecting
compatibility testing.
As an interim solution when building, set the property skipTests=true:
./build.sh install -DskipTests=true
Shelly McGowan
JBoss, by Red Hat
14 years, 3 months
