<div dir="ltr">I think so. If the call to this mapper is done during in the handleLoginResponse it should do the trick but it should also be able to parse a complex type to extract value of a NameIdType.<br><div dir="ltr"><span style="font-size:13px"><br></span></div><div dir="ltr"><span style="font-size:13px">Le ven. 22 janv. 2016 18:53, Bill Burke <<a href="mailto:bburke@redhat.com" target="_blank">bburke@redhat.com</a>> a écrit :</span></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
So, if you have a maper for the brokerUserId, that would solve the
problem?</div><div bgcolor="#FFFFFF" text="#000000"><br>
<br>
<div>On 1/22/2016 12:19 PM, Jérôme Blanchard
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>
<div>
<div>
<div>
<div>
<div>
<div>Hi, <br>
</div>
Stack trace is joined.<br>
</div>
Using a UsernameTemplateMapper is not enough cause the
broderId keep the transient nameid that is used to
link the IdP to the keycloak Account. <br>
</div>
As soon as the IdP session expires, if I use the IdP
again, a new transient nameId is generated and keycloak
is not able to map the incoming SAML response to the
right keycloak Account. It so open the first login form
and ask for a user name (prepopulated with the
${ALIAS}.${NAMEID} syntax or the mapper value (I am
unable to use the complex type in this
UsernameTemplateMapper (like
${ATTRIBUTE.eduPersonTargetID.value[0]})).<br>
</div>
By the way, this attribute mapper does not override the
brokerUserId : <br>
String brokerUserId = config.getAlias() + "." +
subjectNameID.getValue();
identity.setBrokerUserId(brokerUserId); <br>
</div>
so a transient subjectNameID is a problem even with the
UsernameTemplateMapper...<br>
</div>
<div>It always creates a new link between account and IdP and
this link does not work if the keycloak account already
exists.<br>
</div>
<div><br>
</div>
Do you see more clearly my understanding ? (I'm sorry for my
poor english)<br>
</div>
<div>
<div>
<div>
<div>
<div>
<div><br>
<div class="gmail_quote">
<div dir="ltr">Le ven. 22 janv. 2016 à 17:06, Bill
Burke <<a href="mailto:bburke@redhat.com" target="_blank">bburke@redhat.com</a>>
a écrit :<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"> Can you
show me the actual crash? Stack trace? If
the attribute is parsed correctly, you should
be able to write a UsernameMapper to handle
everything no? <br>
</div>
<div bgcolor="#FFFFFF" text="#000000"> <br>
<div>On 1/22/2016 11:00 AM, Jérôme Blanchard
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>
<div>
<div>Yes exactly. <br>
</div>
But I also need to use this complex
type attribute in the
Endpoint.handleLoginResponse as the
subjectNameID in order to avoid using
the provided transient nameID ;
something like : <br>
<br>
protected Response
handleLoginResponse(String
samlResponse, SAMLDocumentHolder
holder, ResponseType responseType,
String relayState) { <br>
try { <br>
AssertionType assertion =
AssertionUtil.getAssertion(responseType,
realm.getPrivateKey()); <br>
SubjectType subject =
assertion.getSubject(); <br>
SubjectType.STSubType subType =
subject.getSubType(); <br>
NameIDType subjectNameID =
(NameIDType) subType.getBaseID(); <br>
//Map<String, String> notes
= new HashMap<>(); <br>
if (subjectNameID.getFormat() !=
null &&
subjectNameID.getFormat().toString().equals(JBossSAMLURIConstants.NAMEID_FORMAT_TRANSIENT.get()))
{ <br>
if
(assertion.getAttributeStatements() !=
null ) { <br>
for (AttributeStatementType
attrStatement :
assertion.getAttributeStatements()) {
<br>
for
(AttributeStatementType.ASTChoiceType
choice :
attrStatement.getAttributes()) {<br>
AttributeType attribute =
choice.getAttribute(); <br>
if
(attribute.getFriendlyName().equals("eduPersonTargetID")
||
attribute.getName().equals("urn:oid:1.3.6.1.4.1.5923.1.1.1.10"))
{ <br>
if
(!attribute.getAttributeValue().isEmpty())
{ <br>
//TODO Use NameId of
this attribute to replace
subjectNameID <br>
} <br>
} <br>
} <br>
} <br>
(...)<br>
} <br>
}<br>
<br>
</div>
Do you think I need to patch this class
in order to allow this or do you think
there is a way of integration in
keycloak considering the shibboleth
federation use case ?<br>
<br>
</div>
Best regards, Jérôme.<br>
<div>
<div>
<div><br>
<br>
<div>
<div dir="ltr"><span style="font-size:13px"><br>
</span></div>
<div dir="ltr"><span style="font-size:13px">Le ven.
22 janv. 2016 14:56, Bill
Burke <</span><a href="mailto:bburke@redhat.com" target="_blank"></a><a href="mailto:bburke@redhat.com" target="_blank">bburke@redhat.com</a><span style="font-size:13px">> a
écrit :</span></div>
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"> Can you
spell out exactly what you
need here as I'm not
understanding.<br>
<br>
You need to support a
complex attribute type? Is
that it?</div>
<div bgcolor="#FFFFFF" text="#000000"><br>
<br>
<div>On 1/22/2016 4:27 AM,
Jérôme Blanchard wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>Hi Bill,
all, <br>
<br>
</div>
I succeed in
authenticating
via shibboleth
federation
using SAML IdP
but I
encounter
problem.<br>
</div>
One SAML
attribute of
our
authentication
response is
not of type
String but a
fulle NameID
type
(eduPersonTargetId)
and makes the
authentication
crash because
of class
BaseWriter
which is not
able to
serialize an
attribute
which is not a
String (line
176).<br>
</div>
If I avoid
this test,
authentication
works well
using the
UsernameTemplateMapper.<br>
</div>
By the way, it
does not solve
the whole
problem. The
provider user id
and the provider
user name store
the saml auth
response nameid
(and not an
attribute) which
makes the next
IdP SAML session
impossible to
use the same
keycloak account
because of a
change of this
transient
nameid...<br>
</div>
Actually, I don't
see another
solution than
rewriting another
Identity Provider
based on
Shibboleth
attribute as a
fork of the SAML
provider but
including.<br>
</div>
It will also allows
me to include the
Shibboleth DIscovery
Service directly in
keycloak instead of
providing another
webapp to ensure the
federation idps
synchronization by
parsing periodiccaly
the WAYF file.<br>
</div>
I will also provide a
small patch for the
BaseWriter in order to
allow serialization of
complex types
attribute, except if
you have in mind to do
so...<br>
<br>
</div>
Best regards, Jérôme.<br>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr">Le jeu.
14 janv. 2016 à 15:37,
Jérôme Blanchard <<a href="mailto:jayblanc@gmail.com" target="_blank"></a><a href="mailto:jayblanc@gmail.com" target="_blank">jayblanc@gmail.com</a>>
a écrit :<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div>
<div>Thanks for
your answer.<br>
</div>
In fact Shibboleth
supports others
saml nameid but in
the renater
federation, it
only contains
transient nameid.
Here is a part of
their doc (sorry
it's in french) :
<br>
<h2><a name="1288646468_msg-f:1524089694669582589_msg-f:1524082976564739697_msg-f:1524080979926326179_msg-f:1524080948012771841_msg-f:1524074810140845538_msg-f:1523352597466697855_utilisation_des_identifiants_utilisateur_opaques">Utilisation
des
identifiants
utilisateur
opaques</a></h2>
<div>
<p> Voir <a href="https://services.renater.fr/federation/faq/shibboleth#definition_d_un_identifiant_utilisateur_opaque" title="federation:faq:shibboleth" target="_blank">la description du
eduPersonTargetedID</a>
</p>
<p> Votre
application a
peut-être
besoin de
manipuler de
identifiants
utilisateur,
dont la valeur
est stable
d'une session
à l'autre ;
par exemple
pour gérer les
préférences
utilisateur.
Or, pour des
raisons de
protection des
données
personnelles,
les
fournisseurs
d'identités ne
peuvent vous
transmettre
les
identifiants
des
utilisateurs.
Dans ce cas,
vous pouvez
demander aux
fournisseurs
d'identités de
vous
communiquer
des
identifiants
stables mais
opaques,
appelés <b>eduPersonTargetedID</b>.
</p>
<p> Vous devrez
configurer le
fichier <i>AAP.xml</i>
de votre
fournisseur de
services
Shibboleth
comme indiqué
ci-dessous : </p>
<pre><AttributeRule Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.10" Header="Shib-TargetedID" Alias="targeted_id">
<AnySite>
<AnyValue/>
</AnySite>
</AttributeRule></pre>
<p> L'attribut
sera
accessible
pour
l'application
dans l'en-tête
<acronym title="Hyper
Text Transfer
Protocol">HTTP</acronym>
<b><acronym title="Hyper
Text Transfer
Protocol">HTTP</acronym>_SHIB_TARGETEDID</b>
(avec
Shibboleth
1.3). Le
format du
eduPersonTargetedID
est le suivant
:
identifiant_IdP<b>!</b>identifiant_SP<b>!</b>identifiant_utilisateur
<br>
</p>
<p><br>
</p>
<p>According to
their doc,
nameid are
session based
and not user
based so if
you want
stable
identifier,
you have to
ask for
eduPersonTargetedID
attribute !!<br>
</p>
</div>
I'm going to have
a look at
UsernameTemplateMapper.<br>
</div>
Thanks again,
Jérôme.<br>
<div>
<h2><a name="1288646468_msg-f:1524089694669582589_msg-f:1524082976564739697_msg-f:1524080979926326179_msg-f:1524080948012771841_msg-f:1524074810140845538_msg-f:1523352597466697855_comment_configurer_un_fournisseur_de_services_pour_qu_il_soit_reconnu_par_plusieurs_federations"></a></h2>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr">Le jeu.
14 janv. 2016
à 15:23, Bill
Burke <<a href="mailto:bburke@redhat.com" target="_blank"></a><a href="mailto:bburke@redhat.com" target="_blank">bburke@redhat.com</a>>
a écrit :<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
Shibboleth only
supports
transient name
ids? I find
that hard to
believe.
Remember
Keycloak would
just look like
any other
client. IMO you
should go that
route.<br>
<br>
Also though, I
think you might
be able to write
a Broker Mapper,
take a look at
UsernameTemplateMapper.
This SPI is
undocumented and
unsupported at
the moment, but
I hope to change
that soon.</div>
<div bgcolor="#FFFFFF" text="#000000"><br>
<br>
<div>On
1/14/2016 6:20
AM, Jérôme
Blanchard
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>
<div>
<div>
<div>
<div>
<div>Hi all, <br>
<br>
</div>
According to
shibboleth
specification,
IdP of a
federation
usually use
transient
NameID which
makes
Shibboleth
impossible to
interface with
keycloak, even
if we manage
the Discovery
Service
externally in
order to
maintain IdP
list mapping
between
federation and
keycloak.<br>
</div>
It's really
annoying for
me and I'm
trying to
investigate a
way to solve
this problem.<br>
</div>
In my
federation,
some doc say
that if you
need to manage
personnal user
information in
your
application,
you have to
rely on a
dedicated
attribute in
order to
retreive real
user id and
not the
transient
opaque one. In
this case, an
attribute
called
eduPersoneTargetedId
exists and can
be use by
shibboleth. <br>
</div>
I am trying to
patch the saml
broker in
order to take
into
consideration
this attribute
in a kind of
attributeToNameIdMapper
but I have to
admit that I'm
lost a bit in
the code.<br>
</div>
Do you think
this approach
is good ?<br>
<br>
</div>
<div>Best
regards,
Jérôme.<br>
</div>
<br>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr">Le mer.
6 janv. 2016
à 09:31,
Jérôme
Blanchard <<a href="mailto:jayblanc@gmail.com" target="_blank"></a><a href="mailto:jayblanc@gmail.com" target="_blank">jayblanc@gmail.com</a>>
a écrit :<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div>
<div>
<div>Hi Bill,
all, <br>
<br>
</div>
In the case of
a transient
only nameid,
would it be
possible to
create a
dedicated
attribute
mapper in
order to use
for exemple
the email
attribute as
name
identifier ?<br>
<br>
</div>
PS : the
urn:mace:shibboleth:1.0:nameIdentifier
is in fact use
in SAML v1 for
request a
nameid that is
transient
also... so
there is no
solution in
this way.<br>
<br>
</div>
Best regards,
Jérôme.<br>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr">Le mar.
5 janv. 2016
à 16:13, Bill
Burke <<a href="mailto:bburke@redhat.com" target="_blank"></a><a href="mailto:bburke@redhat.com" target="_blank">bburke@redhat.com</a>>
a écrit :<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">We
won't be able
to support
temporary ids
(transient)
for awhile as
it<br>
requires
temporary user
creation which
requires some
rearchitecting.<br>
<br>
As for
"urn:mace:shibboleth:1.0:nameIdentifier"
if you spec it
out in a<br>
JIRA and it is
simple enough
to implement
support for,
we may be able
to<br>
get it in.<br>
<br>
On 1/5/2016
8:18 AM,
Jérôme
Blanchard
wrote:<br>
> Hi Bill,<br>
><br>
> Thanks
for your
answer
regarding
transient and
temporary ids.
I<br>
>
understand the
problem due to
keycloak
account
creation and
binding to<br>
> the IdP.<br>
> Renarter
is using
Shibboleth ;
Is there is
any work on
shibboleth<br>
>
integration
for keycloak ?<br>
> If I look
into the idps
entities
descriptors of
renater, I
found that it<br>
> uses also
another nameid
format based
on shibboleth
namesapce :<br>
>
<md:NameIDFormat>urn:mace:shibboleth:1.0:nameIdentifier</md:NameIDFormat><br>
>
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</md:NameIDFormat><br>
><br>
> Do you
think it is
possible to
patch the saml
idp provider
(or to create<br>
> another
one dedicated
to shibboleth)
in order to
integrate
keycloak to<br>
> our
identity
federation
(renater) ?<br>
><br>
> Best
whiches for
this upcoming
year and
thanks for
your great
work<br>
> around
keycloak.<br>
><br>
> Jérôme.<br>
><br>
><br>
> Le mar.
22 déc. 2015 à
21:10, Bill
Burke <<a href="mailto:bburke@redhat.com" target="_blank"></a><a href="mailto:bburke@redhat.com" target="_blank">bburke@redhat.com</a><br>
>
<mailto:<a href="mailto:bburke@redhat.com" target="_blank"></a><a href="mailto:bburke@redhat.com" target="_blank">bburke@redhat.com</a>>>
a écrit :<br>
><br>
> Our
brokering
doesn't
support
temporary user
ids from the
"parent" IDP.<br>
>
Transient Ids
in SAML or
temporary ids.<br>
><br>
> On
12/22/2015
11:46 AM,
Jérôme
Blanchard
wrote:<br>
> >
Hi,<br>
> ><br>
> >
I'm trying to
integrate
keycloak into
a the french
research<br>
>
federation<br>
> >
of identity
(renater) and
I'm facing
some problems.<br>
> >
Actually, when
IdP respond to
keycloak i'm
getting the
following<br>
> error
:<br>
> >
PL00084:
Writer:
Unsupported
Attribute<br>
> >
Value:org.keycloak.dom.saml.v2.assertion.NameIDType<br>
> ><br>
> >
It seems that
this IdP is
using
transient
NameID policy
only and<br>
> using<br>
> >
the
unspecified
field in the
idp config in
keycloak
generate this<br>
> >
exception as a
return.<br>
> ><br>
> >
Log of the
keycloak
server is
joined.<br>
> ><br>
> >
I have no idea
of what
happening
because when I
was using the
test<br>
> >
federation,
everything was
working but no
I'm in the
production<br>
> >
federation,
login fails.<br>
> ><br>
> >
The renater
federation is
using
Shibolleth and
keycloak is
not<br>
>
supported<br>
> >
by federation
moderators so
I'm alone in
the dark
now...<br>
> ><br>
> >
Renater
provides an
IdP list that
I have to
parse and<br>
>
synchronized
with<br>
> >
IdP in
keycloak. As a
return I
provide a list
of all
endpoints<br>
> for
each<br>
> >
keycloak
registered IdP
to allow
federation IdP
to answear<br>
>
correctly to<br>
> >
the right
endpoint. All
of this is
done by a
small web app
deployed<br>
> >
aside keycloak
and using REST
API to
synchronize
all the IdP.<br>
> ><br>
> >
One of the IdP
entity
descriptor is
joined. As you
can see, only<br>
> >
transient
nameid policy
is supported
and if I
configure
keycloak<br>
> to
use<br>
> >
email or
persistent, I
received a
response
saying that
the nameid<br>
> is
not<br>
> >
supported :<br>
> ><br>
> >
<samlp:AuthnRequest<br>
>
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"<br>
> >
xmlns="urn:oasis:names:tc:SAML:2.0:assertion"<br>
> ><br>
>
AssertionConsumerServiceURL="<a href="https://demo-auth.ortolang.fr/auth/realms/ortolang/broker/2db5eab3f83cbaa5a322dcf3f9ac552d/endpoint" target="_blank"></a><a href="https://demo-auth.ortolang.fr/auth/realms/ortolang/broker/2db5eab3f83cbaa5a322dcf3f9ac552d/endpoint" target="_blank">https://demo-auth.ortolang.fr/auth/realms/ortolang/broker/2db5eab3f83cbaa5a322dcf3f9ac552d/endpoint</a>"<br>
> >
Destination="<a href="https://janus.cnrs.fr/idp/profile/SAML2/POST/SSO" target="_blank"></a><a href="https://janus.cnrs.fr/idp/profile/SAML2/POST/SSO" target="_blank">https://janus.cnrs.fr/idp/profile/SAML2/POST/SSO</a>"<br>
> >
ForceAuthn="false"
ID="ID_c53b5759-cb97-4e95-b540-877a7a6c625d"<br>
> >
IsPassive="false"
IssueInstant="2015-12-22T16:13:15.987Z"<br>
> >
ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"<br>
> >
Version="2.0"><saml:Issuer<br>
> ><br>
>
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"><a href="https://demo-auth.ortolang.fr/auth/realms/ortolang" target="_blank"></a><a href="https://demo-auth.ortolang.fr/auth/realms/ortolang" target="_blank">https://demo-auth.ortolang.fr/auth/realms/ortolang</a></saml:Issuer><samlp:NameIDPolicy<br>
> >
AllowCreate="true"<br>
> ><br>
>
Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"/></samlp:AuthnRequest><br>
> ><br>
> ><br>
> >
<saml2p:Response
xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol"<br>
> ><br>
>
Destination="<a href="https://demo-auth.ortolang.fr/auth/realms/ortolang/broker/2db5eab3f83cbaa5a322dcf3f9ac552d/endpoint" target="_blank"></a><a href="https://demo-auth.ortolang.fr/auth/realms/ortolang/broker/2db5eab3f83cbaa5a322dcf3f9ac552d/endpoint" target="_blank">https://demo-auth.ortolang.fr/auth/realms/ortolang/broker/2db5eab3f83cbaa5a322dcf3f9ac552d/endpoint</a>"<br>
> >
ID="_9d03761957aade819b6823c35bbab278"<br>
> >
InResponseTo="ID_c53b5759-cb97-4e95-b540-877a7a6c625d"<br>
> >
IssueInstant="2015-12-22T16:13:16.420Z"
Version="2.0"><saml2:Issuer<br>
> >
xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"<br>
> ><br>
>
Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity"><a href="https://janus.cnrs.fr/idp" target="_blank"></a><a href="https://janus.cnrs.fr/idp" target="_blank">https://janus.cnrs.fr/idp</a></saml2:Issuer><saml2p:Status><saml2p:StatusCode<br>
> ><br>
>
Value="urn:oasis:names:tc:SAML:2.0:status:Responder"><saml2p:StatusCode<br>
> ><br>
>
Value="urn:oasis:names:tc:SAML:2.0:status:InvalidNameIDPolicy"/></saml2p:StatusCode><saml2p:StatusMessage>Required<br>
> >
NameID format
not<br>
> >
supported</saml2p:StatusMessage></saml2p:Status></saml2p:Response><br>
> ><br>
> ><br>
> >
Any help would
be gracefully
appreciated.<br>
> ><br>
> >
Thanks a lot,
Jérôme.<br>
> ><br>
> ><br>
> ><br>
> >
_______________________________________________<br>
> >
keycloak-user
mailing list<br>
> >
<a href="mailto:keycloak-user@lists.jboss.org" target="_blank"></a><a href="mailto:keycloak-user@lists.jboss.org" target="_blank">keycloak-user@lists.jboss.org</a>
<mailto:<a href="mailto:keycloak-user@lists.jboss.org" target="_blank"></a><a href="mailto:keycloak-user@lists.jboss.org" target="_blank">keycloak-user@lists.jboss.org</a>><br>
> >
<a href="https://lists.jboss.org/mailman/listinfo/keycloak-user" target="_blank"></a><a href="https://lists.jboss.org/mailman/listinfo/keycloak-user" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-user</a><br>
> ><br>
><br>
> --<br>
> Bill
Burke<br>
>
JBoss, a
division of
Red Hat<br>
> <a href="http://bill.burkecentral.com" target="_blank"></a><a href="http://bill.burkecentral.com" target="_blank">http://bill.burkecentral.com</a><br>
>
_______________________________________________<br>
>
keycloak-user
mailing list<br>
> <a href="mailto:keycloak-user@lists.jboss.org" target="_blank"></a><a href="mailto:keycloak-user@lists.jboss.org" target="_blank">keycloak-user@lists.jboss.org</a>
<mailto:<a href="mailto:keycloak-user@lists.jboss.org" target="_blank"></a><a href="mailto:keycloak-user@lists.jboss.org" target="_blank">keycloak-user@lists.jboss.org</a>><br>
> <a href="https://lists.jboss.org/mailman/listinfo/keycloak-user" target="_blank"></a><a href="https://lists.jboss.org/mailman/listinfo/keycloak-user" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-user</a><br>
><br>
<br>
--<br>
Bill Burke<br>
JBoss, a
division of
Red Hat<br>
<a href="http://bill.burkecentral.com" rel="noreferrer" target="_blank"></a><a href="http://bill.burkecentral.com" target="_blank">http://bill.burkecentral.com</a><br>
</blockquote>
</div>
</blockquote>
</div>
</blockquote>
<br>
<pre cols="72">--
Bill Burke
JBoss, a division of Red Hat
<a href="http://bill.burkecentral.com" target="_blank">http://bill.burkecentral.com</a></pre>
</div>
</blockquote>
</div>
</blockquote>
</div>
</blockquote>
<br>
<pre cols="72">--
Bill Burke
JBoss, a division of Red Hat
<a href="http://bill.burkecentral.com" target="_blank">http://bill.burkecentral.com</a></pre>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<br>
<pre cols="72">--
Bill Burke
JBoss, a division of Red Hat
<a href="http://bill.burkecentral.com" target="_blank">http://bill.burkecentral.com</a></pre>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<br>
<pre cols="72">--
Bill Burke
JBoss, a division of Red Hat
<a href="http://bill.burkecentral.com" target="_blank">http://bill.burkecentral.com</a></pre>
</div></blockquote></div></div>