Connecting with GroupWise-specific SASL provider with JavaMail IMAP

[David Sitsky]

Hi,

I need to develop some code which will connect to a GroupWise IMAP
server. GroupWise has a special mode for "trusted applications", where
once you are authenticated, you can login as any user without entering
in a password.

This is used for developing virus-scanners and other software which
requires access to all the email in a GroupWise mail server.

I have developed a GroupWise-specific SASL provider and have integrated
it into JavaMail, by setting the appropriate properties in a JavaMail
session, and adding this provider to the security framework.

I can see it is getting called when I am trying to connect to the
GroupWise server.

The problem I am facing is as follows. Here is an example IMAP
conversation with my GroupWise server:

S: * OK GroupWise IMAP4rev1 Server Ready
C: A010 AUTHENTICATE XGWTRUSTEDAPP
S: +
C: XGWTRUSTEDAPP ZmJpADQ5NjRBNjAxMTgxNjAwMDBCNjAwRDIwMDdDMDA
4NTAwNDk2NEE2MDIxODE2MDAwMEI2MDBEMjAwN0MwMDg1MDAA
S: A010 OK XGWTRUSTEDAPP authentication successful

The client response data after XGWTRUSTEDAPP is the base64 encoding of
the special GroupWise "application ID + key".

What is currently causing a problem is the GroupWise IMAP server needs
the "XGWTRUSTEDAPP " string before this base 64 data in the challenge
response.

Looking at the code in IMAPSaslAuthenticator.java, it rightly base64
encodes the response, but doesn't provide any way for me to insert the
"XGWTRUSTEDAPP " string before this base64 data.

Is there any way I can achieve this? Is the GroupWise
challenge/response mechanism here not SASL compliant? Is there a better
way for me to achieve this?

Thanks for any help or suggestions.

Cheers,
David



--
Cheers,
David

This message is intended only for the named recipient. If you are
not the intended recipient you are notified that disclosing, copying,
distributing or taking any action in reliance on the contents of this
information is strictly prohibited.

Nuix Australia Pty Ltd
Suite 79
89 Jones St
Ultimo NSW 2007

Phone: [phone]
Fax: [phone]

===========================================================================
To unsubscribe, send email to ***@java.sun.com and include in the body
of the message "signoff JAVAMAIL-INTEREST". For general help, send email to
***@java.sun.com and include in the body of the message "help".

[Bill Shannon]

Post by David Sitsky
Hi,
I need to develop some code which will connect to a GroupWise IMAP
server. GroupWise has a special mode for "trusted applications", where
once you are authenticated, you can login as any user without entering
in a password.
This is used for developing virus-scanners and other software which
requires access to all the email in a GroupWise mail server.
I have developed a GroupWise-specific SASL provider and have integrated
it into JavaMail, by setting the appropriate properties in a JavaMail
session, and adding this provider to the security framework.
I can see it is getting called when I am trying to connect to the
GroupWise server.
The problem I am facing is as follows. Here is an example IMAP
S: * OK GroupWise IMAP4rev1 Server Ready
C: A010 AUTHENTICATE XGWTRUSTEDAPP
S: +
C: XGWTRUSTEDAPP ZmJpADQ5NjRBNjAxMTgxNjAwMDBCNjAwRDIwMDdDMDA
4NTAwNDk2NEE2MDIxODE2MDAwMEI2MDBEMjAwN0MwMDg1MDAA
S: A010 OK XGWTRUSTEDAPP authentication successful
The client response data after XGWTRUSTEDAPP is the base64 encoding of
the special GroupWise "application ID + key".
What is currently causing a problem is the GroupWise IMAP server needs
the "XGWTRUSTEDAPP " string before this base 64 data in the challenge
response.
Looking at the code in IMAPSaslAuthenticator.java, it rightly base64
encodes the response, but doesn't provide any way for me to insert the
"XGWTRUSTEDAPP " string before this base64 data.
Is there any way I can achieve this? Is the GroupWise
challenge/response mechanism here not SASL compliant? Is there a better
way for me to achieve this?

They're not following the IMAP AUTHENTICATE command spec, which says:

The authentication protocol exchange consists of a series of
server challenges and client responses that are specific to the
authentication mechanism. A server challenge consists of a
command continuation request response with the "+" token followed
by a BASE64 encoded string. The client response consists of a
single line consisting of a BASE64 encoded string. ...

Given that you're authenticating with the XGWTRUSTEDAPP
mechanism, I don't see what the point is of including
XGWTRUSTEDAPP in the response.

Maybe you could report this as a protocol violation to Novell and
see if they're willing to fix it?

I also don't see an easy way to do this within the current
structure of JavaMail's SASL support. If Novell won't fix this bug,
the best thing to do is probably to add yet another server-specific
hack to JavaMail to handle this case, something like this:

------- IMAPSaslAuthenticator.java -------
*** /tmp/sccs.xdaGCe Thu Aug 31 10:21:07 2006
--- IMAPSaslAuthenticator.java Thu Aug 31 10:20:48 2006
***************
*** 163,168 ****
--- 163,170 ----
ByteArrayOutputStream bos = new ByteArrayOutputStream();
byte[] CRLF = { (byte)'\r', (byte)'\n'};

+ // Hack for Novell GroupWise XGWTRUSTEDAPP authentication mechanism
+ boolean isXGWTRUSTEDAPP = sc.getMechanismName().equals("XGWTRUSTEDAPP");
while (!done) { // loop till we are done
try {
r = pr.readResponse();
***************
*** 188,193 ****
--- 190,197 ----
out.println("IMAP SASL DEBUG: response: " +
ASCIIUtility.toString(ba, 0, ba.length) + " :");
ba = BASE64EncoderStream.encode(ba);
+ if (isXGWTRUSTEDAPP)
+ bos.write("XGWTRUSTEDAPP ".getBytes());
bos.write(ba);

bos.write(CRLF); // CRLF termination


Any chance you're going to make your XGWTRUSTEDAPP SASL support available
to others? If so, I'd be more willing to add the above to JavaMail.

===========================================================================
To unsubscribe, send email to ***@java.sun.com and include in the body
of the message "signoff JAVAMAIL-INTEREST". For general help, send email to
***@java.sun.com and include in the body of the message "help".

[David Sitsky]

Post by Bill Shannon

Post by David Sitsky
Hi,
[...]
The problem I am facing is as follows. Here is an example IMAP
S: * OK GroupWise IMAP4rev1 Server Ready
C: A010 AUTHENTICATE XGWTRUSTEDAPP
S: +
C: XGWTRUSTEDAPP ZmJpADQ5NjRBNjAxMTgxNjAwMDBCNjAwRDIwMDdDMDA
4NTAwNDk2NEE2MDIxODE2MDAwMEI2MDBEMjAwN0MwMDg1MDAA
S: A010 OK XGWTRUSTEDAPP authentication successful
The client response data after XGWTRUSTEDAPP is the base64 encoding of
the special GroupWise "application ID + key".
What is currently causing a problem is the GroupWise IMAP server needs
the "XGWTRUSTEDAPP " string before this base 64 data in the challenge
response.
[...]

The authentication protocol exchange consists of a series of
server challenges and client responses that are specific to the
authentication mechanism. A server challenge consists of a
command continuation request response with the "+" token followed
by a BASE64 encoded string. The client response consists of a
single line consisting of a BASE64 encoded string. ...
Given that you're authenticating with the XGWTRUSTEDAPP
mechanism, I don't see what the point is of including
XGWTRUSTEDAPP in the response.
Maybe you could report this as a protocol violation to Novell and
see if they're willing to fix it?

I'll definitely send this report to Novell. Thanks for the explanation.

Post by Bill Shannon
I also don't see an easy way to do this within the current
structure of JavaMail's SASL support. If Novell won't fix this bug,
the best thing to do is probably to add yet another server-specific

Thanks for the advice... such a shame the "hack" is needed, thanks
Novell. :)

Post by Bill Shannon
Any chance you're going to make your XGWTRUSTEDAPP SASL support available
to others? If so, I'd be more willing to add the above to JavaMail.

Once the code is stable, and if I get approval from management, no
worries. Its pretty simple code.

Thanks again for your prompt response.

--
Cheers,
David

This message is intended only for the named recipient. If you are
not the intended recipient you are notified that disclosing, copying,
distributing or taking any action in reliance on the contents of this
information is strictly prohibited.

Nuix Australia Pty Ltd
Suite 79
89 Jones St
Ultimo NSW 2007

Phone: [phone]
Fax: [phone]

===========================================================================
To unsubscribe, send email to ***@java.sun.com and include in the body
of the message "signoff JAVAMAIL-INTEREST". For general help, send email to
***@java.sun.com and include in the body of the message "help".

[jm]

just saw this, and I'm going to find exactly the same scenario with
groupise in the following days, did anything got contrituted in the
end?

thanks
javier

Post by David Sitsky

Post by Bill Shannon

Post by David Sitsky
Hi,
[...]
The problem I am facing is as follows. Here is an example IMAP
S: * OK GroupWise IMAP4rev1 Server Ready
C: A010 AUTHENTICATE XGWTRUSTEDAPP
S: +
C: XGWTRUSTEDAPP ZmJpADQ5NjRBNjAxMTgxNjAwMDBCNjAwRDIwMDdDMDA
4NTAwNDk2NEE2MDIxODE2MDAwMEI2MDBEMjAwN0MwMDg1MDAA
S: A010 OK XGWTRUSTEDAPP authentication successful
The client response data after XGWTRUSTEDAPP is the base64 encoding of
the special GroupWise "application ID + key".
What is currently causing a problem is the GroupWise IMAP server needs
the "XGWTRUSTEDAPP " string before this base 64 data in the challenge
response.
[...]

The authentication protocol exchange consists of a series of
server challenges and client responses that are specific to the
authentication mechanism. A server challenge consists of a
command continuation request response with the "+" token followed
by a BASE64 encoded string. The client response consists of a
single line consisting of a BASE64 encoded string. ...
Given that you're authenticating with the XGWTRUSTEDAPP
mechanism, I don't see what the point is of including
XGWTRUSTEDAPP in the response.
Maybe you could report this as a protocol violation to Novell and
see if they're willing to fix it?

I'll definitely send this report to Novell. Thanks for the explanation.

Post by Bill Shannon
I also don't see an easy way to do this within the current
structure of JavaMail's SASL support. If Novell won't fix this bug,
the best thing to do is probably to add yet another server-specific

Thanks for the advice... such a shame the "hack" is needed, thanks
Novell. :)

Post by Bill Shannon
Any chance you're going to make your XGWTRUSTEDAPP SASL support available
to others? If so, I'd be more willing to add the above to JavaMail.

Once the code is stable, and if I get approval from management, no
worries. Its pretty simple code.
Thanks again for your prompt response.
--
Cheers,
David
This message is intended only for the named recipient. If you are
not the intended recipient you are notified that disclosing, copying,
distributing or taking any action in reliance on the contents of this
information is strictly prohibited.
Nuix Australia Pty Ltd
Suite 79
89 Jones St
Ultimo NSW 2007
Phone: [phone]
Fax: [phone]
===========================================================================
of the message "signoff JAVAMAIL-INTEREST". For general help, send email to

===========================================================================
To unsubscribe, send email to ***@java.sun.com and include in the body
of the message "signoff JAVAMAIL-INTEREST". For general help, send email to
***@java.sun.com and include in the body of the message "help".

[Bill Shannon]

Yes, there's a hack in JavaMail 1.4.1 for this. Let me know if it works
for you too.

Post by jm
just saw this, and I'm going to find exactly the same scenario with
groupise in the following days, did anything got contrituted in the
end?
thanks
javier

Post by David Sitsky

Post by Bill Shannon

Post by David Sitsky
Hi,
[...]
The problem I am facing is as follows. Here is an example IMAP
S: * OK GroupWise IMAP4rev1 Server Ready
C: A010 AUTHENTICATE XGWTRUSTEDAPP
S: +
C: XGWTRUSTEDAPP ZmJpADQ5NjRBNjAxMTgxNjAwMDBCNjAwRDIwMDdDMDA
4NTAwNDk2NEE2MDIxODE2MDAwMEI2MDBEMjAwN0MwMDg1MDAA
S: A010 OK XGWTRUSTEDAPP authentication successful
The client response data after XGWTRUSTEDAPP is the base64 encoding of
the special GroupWise "application ID + key".
What is currently causing a problem is the GroupWise IMAP server needs
the "XGWTRUSTEDAPP " string before this base 64 data in the challenge
response.
[...]

The authentication protocol exchange consists of a series of
server challenges and client responses that are specific to the
authentication mechanism. A server challenge consists of a
command continuation request response with the "+" token followed
by a BASE64 encoded string. The client response consists of a
single line consisting of a BASE64 encoded string. ...
Given that you're authenticating with the XGWTRUSTEDAPP
mechanism, I don't see what the point is of including
XGWTRUSTEDAPP in the response.
Maybe you could report this as a protocol violation to Novell and
see if they're willing to fix it?

I'll definitely send this report to Novell. Thanks for the explanation.

Post by Bill Shannon
I also don't see an easy way to do this within the current
structure of JavaMail's SASL support. If Novell won't fix this bug,
the best thing to do is probably to add yet another server-specific

Thanks for the advice... such a shame the "hack" is needed, thanks
Novell. :)

Post by Bill Shannon
Any chance you're going to make your XGWTRUSTEDAPP SASL support available
to others? If so, I'd be more willing to add the above to JavaMail.

Once the code is stable, and if I get approval from management, no
worries. Its pretty simple code.
Thanks again for your prompt response.
--
Cheers,
David
This message is intended only for the named recipient. If you are
not the intended recipient you are notified that disclosing, copying,
distributing or taking any action in reliance on the contents of this
information is strictly prohibited.
Nuix Australia Pty Ltd
Suite 79
89 Jones St
Ultimo NSW 2007
Phone: [phone]
Fax: [phone]
===========================================================================
of the message "signoff JAVAMAIL-INTEREST". For general help, send email to

===========================================================================
of the message "signoff JAVAMAIL-INTEREST". For general help, send email to

===========================================================================
To unsubscribe, send email to ***@java.sun.com and include in the body
of the message "signoff JAVAMAIL-INTEREST". For general help, send email to
***@java.sun.com and include in the body of the message "help".

[jm]

I understand the 'hack' got into javamail, but not the XGWTRUSTEDAPP
SASL support ?? Or the support is just that small hack??

thanks

Post by Bill Shannon
Yes, there's a hack in JavaMail 1.4.1 for this. Let me know if it works
for you too.

Post by jm
just saw this, and I'm going to find exactly the same scenario with
groupise in the following days, did anything got contrituted in the
end?
thanks
javier

Post by David Sitsky

Post by Bill Shannon

Post by David Sitsky
Hi,
[...]
The problem I am facing is as follows. Here is an example IMAP
S: * OK GroupWise IMAP4rev1 Server Ready
C: A010 AUTHENTICATE XGWTRUSTEDAPP
S: +
C: XGWTRUSTEDAPP ZmJpADQ5NjRBNjAxMTgxNjAwMDBCNjAwRDIwMDdDMDA
4NTAwNDk2NEE2MDIxODE2MDAwMEI2MDBEMjAwN0MwMDg1MDAA
S: A010 OK XGWTRUSTEDAPP authentication successful
The client response data after XGWTRUSTEDAPP is the base64 encoding of
the special GroupWise "application ID + key".
What is currently causing a problem is the GroupWise IMAP server needs
the "XGWTRUSTEDAPP " string before this base 64 data in the challenge
response.
[...]

The authentication protocol exchange consists of a series of
server challenges and client responses that are specific to the
authentication mechanism. A server challenge consists of a
command continuation request response with the "+" token followed
by a BASE64 encoded string. The client response consists of a
single line consisting of a BASE64 encoded string. ...
Given that you're authenticating with the XGWTRUSTEDAPP
mechanism, I don't see what the point is of including
XGWTRUSTEDAPP in the response.
Maybe you could report this as a protocol violation to Novell and
see if they're willing to fix it?

I'll definitely send this report to Novell. Thanks for the explanation.

Post by Bill Shannon
I also don't see an easy way to do this within the current
structure of JavaMail's SASL support. If Novell won't fix this bug,
the best thing to do is probably to add yet another server-specific

Thanks for the advice... such a shame the "hack" is needed, thanks
Novell. :)

Post by Bill Shannon
Any chance you're going to make your XGWTRUSTEDAPP SASL support available
to others? If so, I'd be more willing to add the above to JavaMail.

Once the code is stable, and if I get approval from management, no
worries. Its pretty simple code.
Thanks again for your prompt response.
--
Cheers,
David
This message is intended only for the named recipient. If you are
not the intended recipient you are notified that disclosing, copying,
distributing or taking any action in reliance on the contents of this
information is strictly prohibited.
Nuix Australia Pty Ltd
Suite 79
89 Jones St
Ultimo NSW 2007
Phone: [phone]
Fax: [phone]
===========================================================================
of the message "signoff JAVAMAIL-INTEREST". For general help, send email to

===========================================================================
of the message "signoff JAVAMAIL-INTEREST". For general help, send email to

===========================================================================
To unsubscribe, send email to ***@java.sun.com and include in the body
of the message "signoff JAVAMAIL-INTEREST". For general help, send email to
***@java.sun.com and include in the body of the message "help".

[Bill Shannon]

Just the hack to allow the XGWTRUSTEDAPP SASL support to work.
You'll still need the XGWTRUSTEDAPP SASL support. Hopefully
David has made that available.

Post by jm
I understand the 'hack' got into javamail, but not the XGWTRUSTEDAPP
SASL support ?? Or the support is just that small hack??
thanks

Post by Bill Shannon
Yes, there's a hack in JavaMail 1.4.1 for this. Let me know if it works
for you too.

Post by jm
just saw this, and I'm going to find exactly the same scenario with
groupise in the following days, did anything got contrituted in the
end?
thanks
javier

Post by David Sitsky

Post by Bill Shannon

Post by David Sitsky
Hi,
[...]
The problem I am facing is as follows. Here is an example IMAP
S: * OK GroupWise IMAP4rev1 Server Ready
C: A010 AUTHENTICATE XGWTRUSTEDAPP
S: +
C: XGWTRUSTEDAPP ZmJpADQ5NjRBNjAxMTgxNjAwMDBCNjAwRDIwMDdDMDA
4NTAwNDk2NEE2MDIxODE2MDAwMEI2MDBEMjAwN0MwMDg1MDAA
S: A010 OK XGWTRUSTEDAPP authentication successful
The client response data after XGWTRUSTEDAPP is the base64 encoding of
the special GroupWise "application ID + key".
What is currently causing a problem is the GroupWise IMAP server needs
the "XGWTRUSTEDAPP " string before this base 64 data in the challenge
response.
[...]

The authentication protocol exchange consists of a series of
server challenges and client responses that are specific to the
authentication mechanism. A server challenge consists of a
command continuation request response with the "+" token followed
by a BASE64 encoded string. The client response consists of a
single line consisting of a BASE64 encoded string. ...
Given that you're authenticating with the XGWTRUSTEDAPP
mechanism, I don't see what the point is of including
XGWTRUSTEDAPP in the response.
Maybe you could report this as a protocol violation to Novell and
see if they're willing to fix it?

I'll definitely send this report to Novell. Thanks for the explanation.

Post by Bill Shannon
I also don't see an easy way to do this within the current
structure of JavaMail's SASL support. If Novell won't fix this bug,
the best thing to do is probably to add yet another server-specific

Thanks for the advice... such a shame the "hack" is needed, thanks
Novell. :)

Post by Bill Shannon
Any chance you're going to make your XGWTRUSTEDAPP SASL support available
to others? If so, I'd be more willing to add the above to JavaMail.

Once the code is stable, and if I get approval from management, no
worries. Its pretty simple code.
Thanks again for your prompt response.
--
Cheers,
David
This message is intended only for the named recipient. If you are
not the intended recipient you are notified that disclosing, copying,
distributing or taking any action in reliance on the contents of this
information is strictly prohibited.
Nuix Australia Pty Ltd
Suite 79
89 Jones St
Ultimo NSW 2007
Phone: [phone]
Fax: [phone]
===========================================================================
of the message "signoff JAVAMAIL-INTEREST". For general help, send email to

===========================================================================
of the message "signoff JAVAMAIL-INTEREST". For general help, send email to

===========================================================================
To unsubscribe, send email to ***@java.sun.com and include in the body
of the message "signoff JAVAMAIL-INTEREST". For general help, send email to
***@java.sun.com and include in the body of the message "help".

[jm]

Hi,

I contaced David and unfortunately he was not allowed to donate the
code. So I am trying to build it myself. I have made some progress but
I have already a problem that must be overcome. I am working mostly by
trial and error so bear with me if I make big mistakes.

I have built a provider GroupwiseSaslProvider (and associated factory
etc), that provides only:
put("SaslClientFactory.XGWTRUSTEDAPP",
"com.etc.sasl.GwTrustedAppClientFactoryImpl");
and I have added to the security providers:
Security.insertProviderAt(new
com.etc.sasl.GroupwiseSaslProvider(imapMta.getTrustedAppKey()), 1);

The problem is, my javamail program picks PLAIN authentication before
XGWTRUSTEDAPP authentication. If before adding my provided, I remove
all other existing providers, then my provider kicks in, and the sasl
authentication works (I have to debug more but at least logs in ok
etc). But without the rest of the providers other parts of my code
break of course (https etc).

I am of course sure there must be some easy way to make my code use
XGWTRUSTEDAPP instead of PLAIN without removing all other providers.
Can someone point me to it?

I might be able to provide my working implementation when it works to
you Bill if you can make so use of it, not sure about its overall
quality though.

regards,
javier

Post by Bill Shannon
Just the hack to allow the XGWTRUSTEDAPP SASL support to work.
You'll still need the XGWTRUSTEDAPP SASL support. Hopefully
David has made that available.

Post by jm
I understand the 'hack' got into javamail, but not the XGWTRUSTEDAPP
SASL support ?? Or the support is just that small hack??
thanks

Post by Bill Shannon
Yes, there's a hack in JavaMail 1.4.1 for this. Let me know if it works
for you too.

Post by jm
just saw this, and I'm going to find exactly the same scenario with
groupise in the following days, did anything got contrituted in the
end?
thanks
javier

Post by David Sitsky

Post by Bill Shannon

Post by David Sitsky
Hi,
[...]
The problem I am facing is as follows. Here is an example IMAP
S: * OK GroupWise IMAP4rev1 Server Ready
C: A010 AUTHENTICATE XGWTRUSTEDAPP
S: +
C: XGWTRUSTEDAPP ZmJpADQ5NjRBNjAxMTgxNjAwMDBCNjAwRDIwMDdDMDA
4NTAwNDk2NEE2MDIxODE2MDAwMEI2MDBEMjAwN0MwMDg1MDAA
S: A010 OK XGWTRUSTEDAPP authentication successful
The client response data after XGWTRUSTEDAPP is the base64 encoding of
the special GroupWise "application ID + key".
What is currently causing a problem is the GroupWise IMAP server needs
the "XGWTRUSTEDAPP " string before this base 64 data in the challenge
response.
[...]

The authentication protocol exchange consists of a series of
server challenges and client responses that are specific to the
authentication mechanism. A server challenge consists of a
command continuation request response with the "+" token followed
by a BASE64 encoded string. The client response consists of a
single line consisting of a BASE64 encoded string. ...
Given that you're authenticating with the XGWTRUSTEDAPP
mechanism, I don't see what the point is of including
XGWTRUSTEDAPP in the response.
Maybe you could report this as a protocol violation to Novell and
see if they're willing to fix it?

I'll definitely send this report to Novell. Thanks for the explanation.

Post by Bill Shannon
I also don't see an easy way to do this within the current
structure of JavaMail's SASL support. If Novell won't fix this bug,
the best thing to do is probably to add yet another server-specific

Thanks for the advice... such a shame the "hack" is needed, thanks
Novell. :)

Post by Bill Shannon
Any chance you're going to make your XGWTRUSTEDAPP SASL support available
to others? If so, I'd be more willing to add the above to JavaMail.

Once the code is stable, and if I get approval from management, no
worries. Its pretty simple code.
Thanks again for your prompt response.
--
Cheers,
David
This message is intended only for the named recipient. If you are
not the intended recipient you are notified that disclosing, copying,
distributing or taking any action in reliance on the contents of this
information is strictly prohibited.
Nuix Australia Pty Ltd
Suite 79
89 Jones St
Ultimo NSW 2007
Phone: [phone]
Fax: [phone]
===========================================================================
of the message "signoff JAVAMAIL-INTEREST". For general help, send
email
to

===========================================================================
of the message "signoff JAVAMAIL-INTEREST". For general help, send
email
to

===========================================================================
To unsubscribe, send email to ***@java.sun.com and include in the body
of the message "signoff JAVAMAIL-INTEREST". For general help, send email to
***@java.sun.com and include in the body of the message "help".

[jm]

And just to get the whole information at the same time, I have a
second problem. When I log by hand on a telnet, I do the follwoing:

* OK [CAPABILITY IMAP4rev1 AUTH=PLAIN AUTH=XGWTRUSTEDAPP UNSELECT XGWEXTENSIONS]
Server Ready
A0 AUTHENTICATE XGWTRUSTEDAPP
+
XGWTRUSTEDAPP R1dBVEVNUE8AQjVENzIxNjEwRjgyMDAwMDg0QkJFMDAwNzMwMDk3MDBCNUQ3MjE2Mj
BGODIwMDAwODRCQkUwMDA3MzAwOTcwMAA=
A0 OK XGWTRUSTEDAPP authentication successful
. LOGIN USER22
. OK LOGIN completed
. LIST "" "%"
* LIST (\Unmarked) "/" "INBOX"
* LIST (\Noinferiors \Unmarked) "/" "Sent Items"
* LIST (\Unmarked) "/" "Calendar"
* LIST (\Noinferiors \Unmarked) "/" "Tasklist"
* LIST (\Unmarked) "/" "Cabinet"
* LIST (\Noinferiors \Unmarked) "/" "Trash"
. OK LIST completed

When I do it why my java code, all goes as planned, but after getting
A0 OK XGWTRUSTEDAPP authentication successful
my java code does not issue a LOGIN USER22 to go into that user
mailbox (that user is the one set in "mail.imap.sasl.authorizationid".
So the next command, the LIST fails. Any idea on how I am doing
wrong??

many thanks
javier


A0 AUTHENTICATE XGWTRUSTEDAPP
+
XGWTRUSTEDAPP R1dBVEVNUE8AQjVENzIxNjEwRjgyMDAwMDg0QkJFMDAwNzMwMDk3MDBCNUQ3MjE2MjBGODIwMDAwODRCQkUwMDA3MzAwOTcwMAA=

Post by jm
Hi,
I contaced David and unfortunately he was not allowed to donate the
code. So I am trying to build it myself. I have made some progress but
I have already a problem that must be overcome. I am working mostly by
trial and error so bear with me if I make big mistakes.
I have built a provider GroupwiseSaslProvider (and associated factory
put("SaslClientFactory.XGWTRUSTEDAPP",
"com.etc.sasl.GwTrustedAppClientFactoryImpl");
Security.insertProviderAt(new
com.etc.sasl.GroupwiseSaslProvider(imapMta.getTrustedAppKey()), 1);
The problem is, my javamail program picks PLAIN authentication before
XGWTRUSTEDAPP authentication. If before adding my provided, I remove
all other existing providers, then my provider kicks in, and the sasl
authentication works (I have to debug more but at least logs in ok
etc). But without the rest of the providers other parts of my code
break of course (https etc).
I am of course sure there must be some easy way to make my code use
XGWTRUSTEDAPP instead of PLAIN without removing all other providers.
Can someone point me to it?
I might be able to provide my working implementation when it works to
you Bill if you can make so use of it, not sure about its overall
quality though.
regards,
javier

Post by Bill Shannon
Just the hack to allow the XGWTRUSTEDAPP SASL support to work.
You'll still need the XGWTRUSTEDAPP SASL support. Hopefully
David has made that available.

Post by jm
I understand the 'hack' got into javamail, but not the XGWTRUSTEDAPP
SASL support ?? Or the support is just that small hack??
thanks

Post by Bill Shannon
Yes, there's a hack in JavaMail 1.4.1 for this. Let me know if it works
for you too.

Post by jm
just saw this, and I'm going to find exactly the same scenario with
groupise in the following days, did anything got contrituted in the
end?
thanks
javier

Post by David Sitsky

Post by Bill Shannon

Post by David Sitsky
Hi,
[...]
The problem I am facing is as follows. Here is an example IMAP
S: * OK GroupWise IMAP4rev1 Server Ready
C: A010 AUTHENTICATE XGWTRUSTEDAPP
S: +
C: XGWTRUSTEDAPP ZmJpADQ5NjRBNjAxMTgxNjAwMDBCNjAwRDIwMDdDMDA
4NTAwNDk2NEE2MDIxODE2MDAwMEI2MDBEMjAwN0MwMDg1MDAA
S: A010 OK XGWTRUSTEDAPP authentication successful
The client response data after XGWTRUSTEDAPP is the base64 encoding of
the special GroupWise "application ID + key".
What is currently causing a problem is the GroupWise IMAP server needs
the "XGWTRUSTEDAPP " string before this base 64 data in the challenge
response.
[...]

The authentication protocol exchange consists of a series of
server challenges and client responses that are specific to the
authentication mechanism. A server challenge consists of a
command continuation request response with the "+" token followed
by a BASE64 encoded string. The client response consists of a
single line consisting of a BASE64 encoded string. ...
Given that you're authenticating with the XGWTRUSTEDAPP
mechanism, I don't see what the point is of including
XGWTRUSTEDAPP in the response.
Maybe you could report this as a protocol violation to Novell and
see if they're willing to fix it?

I'll definitely send this report to Novell. Thanks for the explanation.

Post by Bill Shannon
I also don't see an easy way to do this within the current
structure of JavaMail's SASL support. If Novell won't fix this bug,
the best thing to do is probably to add yet another server-specific

Thanks for the advice... such a shame the "hack" is needed, thanks
Novell. :)

Post by Bill Shannon
Any chance you're going to make your XGWTRUSTEDAPP SASL support available
to others? If so, I'd be more willing to add the above to JavaMail.

Once the code is stable, and if I get approval from management, no
worries. Its pretty simple code.
Thanks again for your prompt response.
--
Cheers,
David
This message is intended only for the named recipient. If you are
not the intended recipient you are notified that disclosing, copying,
distributing or taking any action in reliance on the contents of this
information is strictly prohibited.
Nuix Australia Pty Ltd
Suite 79
89 Jones St
Ultimo NSW 2007
Phone: [phone]
Fax: [phone]
===========================================================================
of the message "signoff JAVAMAIL-INTEREST". For general help, send
email
to

===========================================================================
of the message "signoff JAVAMAIL-INTEREST". For general help, send
email
to

===========================================================================
To unsubscribe, send email to ***@java.sun.com and include in the body
of the message "signoff JAVAMAIL-INTEREST". For general help, send email to
***@java.sun.com and include in the body of the message "help".

[Bill Shannon]

Post by jm
And just to get the whole information at the same time, I have a
* OK [CAPABILITY IMAP4rev1 AUTH=PLAIN AUTH=XGWTRUSTEDAPP UNSELECT XGWEXTENSIONS]
Server Ready
A0 AUTHENTICATE XGWTRUSTEDAPP
+
XGWTRUSTEDAPP R1dBVEVNUE8AQjVENzIxNjEwRjgyMDAwMDg0QkJFMDAwNzMwMDk3MDBCNUQ3MjE2Mj
BGODIwMDAwODRCQkUwMDA3MzAwOTcwMAA=
A0 OK XGWTRUSTEDAPP authentication successful
. LOGIN USER22
. OK LOGIN completed
. LIST "" "%"
* LIST (\Unmarked) "/" "INBOX"
* LIST (\Noinferiors \Unmarked) "/" "Sent Items"
* LIST (\Unmarked) "/" "Calendar"
* LIST (\Noinferiors \Unmarked) "/" "Tasklist"
* LIST (\Unmarked) "/" "Cabinet"
* LIST (\Noinferiors \Unmarked) "/" "Trash"
. OK LIST completed
When I do it why my java code, all goes as planned, but after getting
A0 OK XGWTRUSTEDAPP authentication successful
my java code does not issue a LOGIN USER22 to go into that user
mailbox (that user is the one set in "mail.imap.sasl.authorizationid".
So the next command, the LIST fails. Any idea on how I am doing
wrong??

After doing the AUTNETHICATE, JavaMail thinks you're already logged in,
so there's no need to issue a login command. Does the XGWTRUSTEDAPP
mechanism give you a way to specify both an authentication ID and an
authorization ID?

===========================================================================
To unsubscribe, send email to ***@java.sun.com and include in the body
of the message "signoff JAVAMAIL-INTEREST". For general help, send email to
***@java.sun.com and include in the body of the message "help".

[jm]

I would not know what to reply here...if it helps, when I set a
breakpoint in IMAPStore, at line 534:

if (enableSASL)
p.sasllogin(saslMechanisms, saslRealm, authzid, u, pw);
authzid has user22 (the one whose mailbox I want to access)
and u has user2 (user given in the session) .


I have make it all work with a dirty hack in IMAPStore, like this:

if (enableSASL)
p.sasllogin(saslMechanisms, saslRealm, authzid, u, pw);
if ("true".equals(System.getProperty("javamail.groupwisesasl"))) {
p.login(authzid, pw);
} else {
if (p.isAuthenticated())
; // SASL login succeeded, go to bottom
else if (p.hasCapability("AUTH=PLAIN") && !disableAuthPlain)
p.authplain(authzid, u, pw);
else if ((p.hasCapability("AUTH-LOGIN") ||
p.hasCapability("AUTH=LOGIN")) && !disableAuthLogin)
p.authlogin(u, pw);
else if (!p.hasCapability("LOGINDISABLED"))
p.login(u, pw);
else
throw new ProtocolException("No login methods supported!");
}

javier

Post by Bill Shannon

Post by jm
And just to get the whole information at the same time, I have a
* OK [CAPABILITY IMAP4rev1 AUTH=PLAIN AUTH=XGWTRUSTEDAPP UNSELECT XGWEXTENSIONS]
Server Ready
A0 AUTHENTICATE XGWTRUSTEDAPP
+
XGWTRUSTEDAPP
R1dBVEVNUE8AQjVENzIxNjEwRjgyMDAwMDg0QkJFMDAwNzMwMDk3MDBCNUQ3MjE2Mj
BGODIwMDAwODRCQkUwMDA3MzAwOTcwMAA=
A0 OK XGWTRUSTEDAPP authentication successful
. LOGIN USER22
. OK LOGIN completed
. LIST "" "%"
* LIST (\Unmarked) "/" "INBOX"
* LIST (\Noinferiors \Unmarked) "/" "Sent Items"
* LIST (\Unmarked) "/" "Calendar"
* LIST (\Noinferiors \Unmarked) "/" "Tasklist"
* LIST (\Unmarked) "/" "Cabinet"
* LIST (\Noinferiors \Unmarked) "/" "Trash"
. OK LIST completed
When I do it why my java code, all goes as planned, but after getting
A0 OK XGWTRUSTEDAPP authentication successful
my java code does not issue a LOGIN USER22 to go into that user
mailbox (that user is the one set in "mail.imap.sasl.authorizationid".
So the next command, the LIST fails. Any idea on how I am doing
wrong??

After doing the AUTNETHICATE, JavaMail thinks you're already logged in,
so there's no need to issue a login command. Does the XGWTRUSTEDAPP
mechanism give you a way to specify both an authentication ID and an
authorization ID?

===========================================================================
To unsubscribe, send email to ***@java.sun.com and include in the body
of the message "signoff JAVAMAIL-INTEREST". For general help, send email to
***@java.sun.com and include in the body of the message "help".

[Bill Shannon]

Post by jm
I would not know what to reply here...if it helps, when I set a
if (enableSASL)
p.sasllogin(saslMechanisms, saslRealm, authzid, u, pw);
authzid has user22 (the one whose mailbox I want to access)
and u has user2 (user given in the session) .

That's a question for someone who understands the XGWTRUSTEDAPP authentication
mechanism. Did you ask David if he handled this case in his implementation?
Is there public documentation for the XGWTRUSTEDAPP mechanism?

===========================================================================
To unsubscribe, send email to ***@java.sun.com and include in the body
of the message "signoff JAVAMAIL-INTEREST". For general help, send email to
***@java.sun.com and include in the body of the message "help".

[jm]

No I didn't ask David any more details, I think he moved on to other stuff.

I found this link where it seems they talk about the LOGIN after authentication:
http://developer.novell.com/documentation/gwimap/index.html?page=/documentation/gwimap/gwimpenu/data/al4pzys.html

Post by Bill Shannon

Post by jm
I would not know what to reply here...if it helps, when I set a
if (enableSASL)
p.sasllogin(saslMechanisms, saslRealm, authzid, u, pw);
authzid has user22 (the one whose mailbox I want to access)
and u has user2 (user given in the session) .

That's a question for someone who understands the XGWTRUSTEDAPP authentication
mechanism. Did you ask David if he handled this case in his implementation?
Is there public documentation for the XGWTRUSTEDAPP mechanism?

===========================================================================
To unsubscribe, send email to ***@java.sun.com and include in the body
of the message "signoff JAVAMAIL-INTEREST". For general help, send email to
***@java.sun.com and include in the body of the message "help".

[Bill Shannon]

Post by jm
Hi,
I contaced David and unfortunately he was not allowed to donate the
code. So I am trying to build it myself. I have made some progress but
I have already a problem that must be overcome. I am working mostly by
trial and error so bear with me if I make big mistakes.
I have built a provider GroupwiseSaslProvider (and associated factory
put("SaslClientFactory.XGWTRUSTEDAPP",
"com.etc.sasl.GwTrustedAppClientFactoryImpl");
Security.insertProviderAt(new
com.etc.sasl.GroupwiseSaslProvider(imapMta.getTrustedAppKey()), 1);
The problem is, my javamail program picks PLAIN authentication before
XGWTRUSTEDAPP authentication. If before adding my provided, I remove
all other existing providers, then my provider kicks in, and the sasl
authentication works (I have to debug more but at least logs in ok
etc). But without the rest of the providers other parts of my code
break of course (https etc).
I am of course sure there must be some easy way to make my code use
XGWTRUSTEDAPP instead of PLAIN without removing all other providers.
Can someone point me to it?

There's a property you can set to disable use of PLAIN authentication.
See the javadocs for the com.sun.mail.imap package.

===========================================================================
To unsubscribe, send email to ***@java.sun.com and include in the body
of the message "signoff JAVAMAIL-INTEREST". For general help, send email to
***@java.sun.com and include in the body of the message "help".

[jm]

Hi Bill,

yes, I saw the property, but setting it to true does not work it for
me (either as string or boolean), see output:
DEBUG: getProvider() returning
javax.mail.Provider[STORE,imap,com.sun.mail.imap.IMAPStore,Sun
Microsystems, Inc]
DEBUG: mail.imap.fetchsize: 16384
DEBUG: mail.imap.statuscachetimeout: 1000
DEBUG: mail.imap.appendbuffersize: -1
DEBUG: mail.imap.minidletime: 10
DEBUG: disable AUTH=PLAIN
DEBUG: enable SASL
DEBUG: mail.imap.sasl.authorizationid: user2
* OK [CAPABILITY IMAP4rev1 AUTH=PLAIN AUTH=XGWTRUSTEDAPP UNSELECT
XGWEXTENSIONS] Server Ready
IMAP DEBUG: AUTH: PLAIN
IMAP DEBUG: AUTH: XGWTRUSTEDAPP
DEBUG: protocolConnect login, host=groupwisehost, user=user2,
password=<non-null>
IMAP SASL DEBUG: Mechanisms: PLAIN XGWTRUSTEDAPP
IMAP SASL DEBUG: callback length: 2
IMAP SASL DEBUG: callback 0: ***@5a5140
IMAP SASL DEBUG: callback 1:
***@18c4b30
IMAP SASL DEBUG: SASL client PLAIN
A0 AUTHENTICATE PLAIN
+
IMAP SASL DEBUG: challenge: :
IMAP SASL DEBUG: response: user2

this is using latest beta of javamail1.4.2 you posted some weeks ago
javier

Post by Bill Shannon

Post by jm
Hi,
I contaced David and unfortunately he was not allowed to donate the
code. So I am trying to build it myself. I have made some progress but
I have already a problem that must be overcome. I am working mostly by
trial and error so bear with me if I make big mistakes.
I have built a provider GroupwiseSaslProvider (and associated factory
put("SaslClientFactory.XGWTRUSTEDAPP",
"com.etc.sasl.GwTrustedAppClientFactoryImpl");
Security.insertProviderAt(new
com.etc.sasl.GroupwiseSaslProvider(imapMta.getTrustedAppKey()), 1);
The problem is, my javamail program picks PLAIN authentication before
XGWTRUSTEDAPP authentication. If before adding my provided, I remove
all other existing providers, then my provider kicks in, and the sasl
authentication works (I have to debug more but at least logs in ok
etc). But without the rest of the providers other parts of my code
break of course (https etc).
I am of course sure there must be some easy way to make my code use
XGWTRUSTEDAPP instead of PLAIN without removing all other providers.
Can someone point me to it?

There's a property you can set to disable use of PLAIN authentication.
See the javadocs for the com.sun.mail.imap package.

===========================================================================
To unsubscribe, send email to ***@java.sun.com and include in the body
of the message "signoff JAVAMAIL-INTEREST". For general help, send email to
***@java.sun.com and include in the body of the message "help".

[jm]

some advance...I resolved that issue by setting
props.put("mail.imap.sasl.mechanisms", "XGWTRUSTEDAPP");
this way that mechanism is always used instead of PLAIN

Post by jm
Hi Bill,
yes, I saw the property, but setting it to true does not work it for
DEBUG: getProvider() returning
javax.mail.Provider[STORE,imap,com.sun.mail.imap.IMAPStore,Sun
Microsystems, Inc]
DEBUG: mail.imap.fetchsize: 16384
DEBUG: mail.imap.statuscachetimeout: 1000
DEBUG: mail.imap.appendbuffersize: -1
DEBUG: mail.imap.minidletime: 10
DEBUG: disable AUTH=PLAIN
DEBUG: enable SASL
DEBUG: mail.imap.sasl.authorizationid: user2
* OK [CAPABILITY IMAP4rev1 AUTH=PLAIN AUTH=XGWTRUSTEDAPP UNSELECT
XGWEXTENSIONS] Server Ready
IMAP DEBUG: AUTH: PLAIN
IMAP DEBUG: AUTH: XGWTRUSTEDAPP
DEBUG: protocolConnect login, host=groupwisehost, user=user2,
password=<non-null>
IMAP SASL DEBUG: Mechanisms: PLAIN XGWTRUSTEDAPP
IMAP SASL DEBUG: callback length: 2
IMAP SASL DEBUG: SASL client PLAIN
A0 AUTHENTICATE PLAIN
+
IMAP SASL DEBUG: response: user2
this is using latest beta of javamail1.4.2 you posted some weeks ago
javier

Post by Bill Shannon

Post by jm
Hi,
I contaced David and unfortunately he was not allowed to donate the
code. So I am trying to build it myself. I have made some progress but
I have already a problem that must be overcome. I am working mostly by
trial and error so bear with me if I make big mistakes.
I have built a provider GroupwiseSaslProvider (and associated factory
put("SaslClientFactory.XGWTRUSTEDAPP",
"com.etc.sasl.GwTrustedAppClientFactoryImpl");
Security.insertProviderAt(new
com.etc.sasl.GroupwiseSaslProvider(imapMta.getTrustedAppKey()), 1);
The problem is, my javamail program picks PLAIN authentication before
XGWTRUSTEDAPP authentication. If before adding my provided, I remove
all other existing providers, then my provider kicks in, and the sasl
authentication works (I have to debug more but at least logs in ok
etc). But without the rest of the providers other parts of my code
break of course (https etc).
I am of course sure there must be some easy way to make my code use
XGWTRUSTEDAPP instead of PLAIN without removing all other providers.
Can someone point me to it?

There's a property you can set to disable use of PLAIN authentication.
See the javadocs for the com.sun.mail.imap package.

===========================================================================
To unsubscribe, send email to ***@java.sun.com and include in the body
of the message "signoff JAVAMAIL-INTEREST". For general help, send email to
***@java.sun.com and include in the body of the message "help".

[Bill Shannon]

Post by jm
some advance...I resolved that issue by setting
props.put("mail.imap.sasl.mechanisms", "XGWTRUSTEDAPP");
this way that mechanism is always used instead of PLAIN

Right. The other property controls the built-in PLAIN support in
JavaMail, but if you enable SASL it also has PLAIN support that is
controlled by the property above.

===========================================================================
To unsubscribe, send email to ***@java.sun.com and include in the body
of the message "signoff JAVAMAIL-INTEREST". For general help, send email to
***@java.sun.com and include in the body of the message "help".