Hello there:
First of all, thanks for replying and thank you very much for
the terrific work you have done implementing jUDDI. Now, about the
issue at hand, that is what I suspected: when someone finds the time
to plug a proper SSO solution in there, then it will be done. Until
then, my dirty hack will have to do.
Best regards.
--
Jose Manuel Arnesto López - R&D Innovation
TELVENT
Telvent Arce Sistemas, S.A.
Telvent - Bilbao - Vizcaya
Phone: +34944224004 (2004) Fax: +34944440658
[email protected]
PEco-Tip: Printing e-mails is usually a waste.
Kurt T Stam
29/08/2011 15:04
Por favor, responda a user
Para:
[email protected]
cc:
Asunto: Re: Trying to make juddi console work with XMLDocAuthenticator
Hi Jose,
These reason this wasn't fully working is that to do it right we need
a full fledged SSO solution. Since
at the moment we are using tomcatSSO your solution is just fine. You
should only have to log into
the portal. The portlet login panel is there for when you want to run
outside of a portal.
Cheers,
--Kurt
On 8/18/11 10:05 AM, [email protected]_
<mailto:[email protected]>wrote:
Well, I have made a small hack in the get(String, String)
method of class SecurityServiceImpl and it works fine now.
Before:
*
if* (username== *null* && user!= *null* ) {
username = user.getName();
password = "" ;
}
After:
*if* ((username== *null* ) && (user!= *null* )) {
username = user.getName();
User tomcatUser = (User) user; // Tomcat specific. Ouch!
password = tomcatUser.getPassword();
}
It is not portable, I don't like it, but it works. All in all,
I wonder what the original developers had in mind to solve this issue
in a more elegant way.
Kind regards.
PS: for some reason, even though I can access the contents of
the registry now, the LoginPanel is not shown. Maybe it was not meant
to be.
--
Jose Manuel Arnesto López - R&D Innovation
TELVENT
Telvent Arce Sistemas, S.A.
Telvent - Bilbao - Vizcaya
Phone: +34944224004 (2004) Fax: +34944440658 _
[email protected]_ <mailto:[email protected]>
P Eco-Tip: Printing e-mails is usually a waste.
jm.arnesto
18/08/2011 12:39
Por favor, responda a user
Para: _
[email protected]_ <mailto:[email protected]>
cc:
Asunto: Re: Trying to make juddi console work with XMLDocAuthenticator
Hello again:
I have carried out a small test. I have changed the
onModuleLoad() method of UDDIBrowser, making the LoginPanel visible
from the beginning:
*public* *void* onModuleLoad() {
/singleton/ = *this* ;
loginPanel = *new* LoginPanel( *this* );
loginPanel .setVisible( *true* );
Then I have removed the initial invocation tot getToken in the
LoginPanel constructor:
*public* LoginPanel(Login application) {
*super* ();
*this* . application = application;
//getToken(null, null);
Besides, the login() method in UDDIBrowser has also been
modified to always make the LoginPanel visible, just in case:
*public* *void* login() {
String token = loginPanel .getToken();
*if* (token == *null* ) {
loginPanel .setVisible( *true* );
} *else* {
loginPanel .setVisible( *true* );
The result of all of that is that the LoginPanel is shown within
the UDDIBrowser portlet in the console and if I enter the username and
password there, the contents of the registry are correctly shown.
However, I guess the point is to be able to use the login
information that is typed when entering pluto to authenticate against
jUDDI, without having to enter the username and password in every
portlet. If that is the case, I guess the code in SecurityServiceImpl
is just not finished. Could anyone comment if that is actually the
case (being new to the project, I am just guessing).
Kind regards.
--
Jose Manuel Arnesto López - R&D Innovation
TELVENT
Telvent Arce Sistemas, S.A.
Telvent - Bilbao - Vizcaya
Phone: +34944224004 (2004) Fax: +34944440658 _
[email protected]_ <mailto:[email protected]>
P Eco-Tip: Printing e-mails is usually a waste.
jm.arnesto
18/08/2011 12:21
Por favor, responda a user
Para: _
[email protected]_ <mailto:[email protected]>
cc:
Asunto: Re: Trying to make juddi console work with XMLDocAuthenticator
Well, now I know why both user and password are null. Let's have
a look at, for instance, class UDDIBrowser
(org.apache.juddi.portlets.client). When that module loads, it creates
a new LoginPanel (org.apache.juddi.portlets.client): *
public* *void* onModuleLoad() {
/singleton/ = *this* ;
loginPanel = *new* LoginPanel( *this* );
loginPanel .setVisible( *false* );
And it is the constructor of LoginPanel that invocates its own
getToken(user, password) method with both parameters as null:
*public* LoginPanel(Login application) {
*super* ();
*this* . application = application;
getToken( *null* , *null* );
[...]
Let's remember that the getToken(user, password) method is as
follows:
*protected* *void* getToken(String user, String password) {
securityService .get(user, password, *new*
AsyncCallback<SecurityResponse>()
{
*public* *void* onFailure(Throwable caught) {
Window./alert/( "Error: " +
caught.getMessage());
}
*public* *void* onSuccess(SecurityResponse response) {
*if* (response.isSuccess()) {
token = response.getResponse();
publisherId =
response.getUsername();
application .login();
} *else* {
Window./alert/( "error: " +
response.getMessage());
}
}
});
}
So on first invocation, the parameters sent to
SecurityServiceImpl (org.apache.juddi.portlets.server.service) are
always to be null. And that causes what I commented at the beginning
of the thread (a token cannot be obtained). If that token was
sucessfull obtained, the LoginPanel itself would be made visible in
the login() method of UDDIBrowser:
*public* *void* login() {
String token = loginPanel .getToken();
*if* (token == *null* ) {
loginPanel .setVisible( *true* );
} *else* {
loginPanel .setVisible( *true* );
applicationPanel .setVisible( *true* );
applicationPanel .findAllBusiness();
}
}
And after that, you could specify a username and password with
that LoginPanel, as can be observed in its onclick(Widget sender) method:
*public* *void* onClick(Widget sender) {
*if* (sender == tokenButton ) {
getToken( usernameBox .getText(), passwordBox
.getText());
} *else* {
System. /err/ .println( "undefined" );
}
}
And in that case, the username and password that are, at the end,
sent to SecutiryServiceImpl, would not be null.
So, going back to where we started, it seems that on first
invocation the username and password sent to method get(String,
String) of SecurityServiceImpl are expected to be null and the
credentials that are going to be sent to jUDDI itself should be gotten
from the login information that was sent to Tomcat on the Pluto login
page. Indeed, the username used there is obtained, bot not its password:
*public* SecurityResponse get(String username, String password) {
HttpServletRequest request = getThreadLocalRequest();
HttpSession session = request.getSession();
[..]
Principal user = request.getUserPrincipal();
[..] *
if* ((username== *null* ) && (user!= *null* )) {
username = user.getName();
password = "" ;
}
[..]
AuthToken authToken = login(username, password,
session.getServletContext());
[..]
All in all, is that a case of some functionality that is simply
not implemented in the console (out of the box supporting some other
authentication than JUDDIAuthenticator)?
Kind regards.
--
Jose Manuel Arnesto López - R&D Innovation
TELVENT
Telvent Arce Sistemas, S.A.
Telvent - Bilbao - Vizcaya
Phone: +34944224004 (2004) Fax: +34944440658 _
[email protected]_ <mailto:[email protected]>
P Eco-Tip: Printing e-mails is usually a waste.
jm.arnesto
18/08/2011 10:39
Por favor, responda a user
Para: _
[email protected]_ <mailto:[email protected]>
cc:
Asunto: Re: Trying to make juddi console work with XMLDocAuthenticator
Hello:
That is a very good question, and that is exactly what I have been
trying to find out as of late. It seems SecurityServiceImpl
(org.apache.juddi.portlets.server.service) is being called from
LoginPanel (org.apache.juddi.portlets.client). It wasn't easy to find
it out, given that I had no idea about GWT. Anyway, this is the method
in question:
*protected* *void* getToken(String user, String password) {
securityService .get(user, password, *new*
AsyncCallback<SecurityResponse>()
{
*public* *void* onFailure(Throwable caught) {
Window./alert/( "Error: " +
caught.getMessage());
}
*public* *void* onSuccess(SecurityResponse response) {
*if* (response.isSuccess()) {
token = response.getResponse();
publisherId =
response.getUsername();
application .login();
} *else* {
Window./alert/( "error: " +
response.getMessage());
}
}
});
}
I have added a Window.alert at the beginning of that method and
the parameters it is receiving are both null (user and password). I
will keep working on this.
Kind regards.
--
Jose Manuel Arnesto López - R&D Innovation
TELVENT
Telvent Arce Sistemas, S.A.
Telvent - Bilbao - Vizcaya
Phone: +34944224004 (2004) Fax: +34944440658 _
[email protected]_ <mailto:[email protected]>
P Eco-Tip: Printing e-mails is usually a waste.
Tom Cunningham
17/08/2011 18:12
Por favor, responda a user
Para: _
[email protected]_ <mailto:[email protected]>
cc:
Asunto: Re: Trying to make juddi console work with XMLDocAuthenticator
On 08/16/2011 09:26 AM, [email protected] _
<mailto:[email protected]>wrote:
log.debug("UserPrincipal " + user);
if (username==null && user!=null) {
username = user.getName();
password = "";
}
Being as I am new to this project, the reason for that may be obvious
but, why is an empty value being assigned to the password variable in
there?
Hi Jose,
I'm probably missing something really basic here, but why is username
null?
--Tom
