JAAS and Java client authentication

I'm trying to use JAAS authentication from a Java Swing client against a
WLS 6.1 SP1 server. Using the samples I've successfully managed to
authenticate a client, however a couple of issues have arisen:
- How can I remove the principal association with the current thread when
the user wishes to log out ? The LoginContext.logout implementation in
the samples doesn't appear to be sufficient.
- I'm assuming that the current server authentication called via
weblogic.security.auth.Authenticate.authenticate does not store roles and
group information as Principals within the returned Subject ? Is there
anyway I can access this information so I can modify the UI for the
current user ?
- Should I be able to establish a secure connection by using
t3s://host:secure_port when authenticating through JAAS ? When I tried
this I received, 'java.rmi.ConnectException - unable to get direct or
routed connection to '904601561764...:<ip address>'
Thanks
Darren

Yes Sun provides a Windows LoginModule implementation called com.sun.security.auth.module.NTLoginModulewhich should do Windows logins (I have not tried it on XP)
However, in order to understand how this all works you have to read the JAAS reference guide and tutorial.
http://java.sun.com/j2se/1.5.0/docs/guide/security/jaas/JAASRefGuide.html
http://java.sun.com/j2se/1.5.0/docs/guide/security/jaas/tutorials/index.html

Similar Messages

Java Client AUthentication to IIS 5 server throwing no IV for Cipher error

I have trying to do Java client authentication. Got the Certificate from CA and loaded it in server. When I run the JavaClient program I get the
error no IV for Cipher.
I am using JDK 1.5.0_06 and JSSE 1.0.3_03.
Any help is greatly appreciated.
Thanks
Here is the debug report
trustStore is: C:\JTEST\cacerts
trustStore type is : JKS
trustStore provider is :
init truststore
adding as trusted cert:
Subject: CN=devclient.test.com, OU=Mycompany, O=Second Data Corporation., L=San Francisco, ST=California, C=US
Issuer: OU=Equifax Secure Certificate Authority, O=Equifax, C=US
Algorithm: RSA; Serial number: 0x5b0bf
Valid from Thu Feb 16 06:23:37 PST 2006 until Sat Feb 17 06:23:37 PST 2007
adding as trusted cert:
Subject: [email protected], CN=http://www.valicert.com/, OU=ValiCert Class 2 Policy Validation Authority, O="ValiCert, Inc.", L=ValiCert Validation Network
Issuer: [email protected], CN=http://www.valicert.com/, OU=ValiCert Class 2 Policy Validation Authority, O="ValiCert, Inc.", L=ValiCert Validation Network
Algorithm: RSA; Serial number: 0x1
Valid from Fri Jun 25 17:19:54 PDT 1999 until Tue Jun 25 17:19:54 PDT 2019
adding as trusted cert:
Subject: CN=Baltimore CyberTrust Code Signing Root, OU=CyberTrust, O=Baltimore, C=IE
Issuer: CN=Baltimore CyberTrust Code Signing Root, OU=CyberTrust, O=Baltimore, C=IE
Algorithm: RSA; Serial number: 0x20000bf
Valid from Wed May 17 07:01:00 PDT 2000 until Sat May 17 16:59:00 PDT 2025
adding as trusted cert:
Subject: CN=Entrust.net Secure Server Certification Authority, OU=(c) 1999 Entrust.net Limited, OU=www.entrust.net/CPS incorp. by ref. (limits liab.), O=Entrust.net, C=US
Issuer: CN=Entrust.net Secure Server Certification Authority, OU=(c) 1999 Entrust.net Limited, OU=www.entrust.net/CPS incorp. by ref. (limits liab.), O=Entrust.net, C=US
Algorithm: RSA; Serial number: 0x374ad243
Valid from Tue May 25 09:09:40 PDT 1999 until Sat May 25 09:39:40 PDT 2019
adding as trusted cert:
Subject: CN=Baltimore CyberTrust Root, OU=CyberTrust, O=Baltimore, C=IE
Issuer: CN=Baltimore CyberTrust Root, OU=CyberTrust, O=Baltimore, C=IE
Algorithm: RSA; Serial number: 0x20000b9
Valid from Fri May 12 11:46:00 PDT 2000 until Mon May 12 16:59:00 PDT 2025
adding as trusted cert:
Subject: CN=devclient.paymap.com, OU=First Data Corp, O=Paymap Inc, L=San Francisco, ST=California, C=USA
Issuer: CN=Thawte Test CA Root, OU=TEST TEST TEST, O=Thawte Certification, ST=FOR TESTING PURPOSES ONLY, C=ZA
Algorithm: RSA; Serial number: 0xe2501de73ac37428
Valid from Mon Feb 20 15:51:25 PST 2006 until Mon Mar 13 15:51:25 PST 2006
adding as trusted cert:
Subject: CN=VeriSign Class 3 Public Primary Certification Authority - G3, OU="(c) 1999 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US
Issuer: CN=VeriSign Class 3 Public Primary Certification Authority - G3, OU="(c) 1999 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US
Algorithm: RSA; Serial number: 0x9b7e0649a33e62b9d5ee90487129ef57
Valid from Thu Sep 30 17:00:00 PDT 1999 until Wed Jul 16 16:59:59 PDT 2036
adding as trusted cert:
Subject: OU=Starfield Class 2 Certification Authority, O="Starfield Technologies, Inc.", C=US
Issuer: OU=Starfield Class 2 Certification Authority, O="Starfield Technologies, Inc.", C=US
Algorithm: RSA; Serial number: 0x0
Valid from Tue Jun 29 10:39:16 PDT 2004 until Thu Jun 29 10:39:16 PDT 2034
adding as trusted cert:
Subject: [email protected], CN=Thawte Personal Basic CA, OU=Certification Services Division, O=Thawte Consulting, L=Cape Town, ST=Western Cape, C=ZA
Issuer: [email protected], CN=Thawte Personal Basic CA, OU=Certification Services Division, O=Thawte Consulting, L=Cape Town, ST=Western Cape, C=ZA
Algorithm: RSA; Serial number: 0x0
Valid from Sun Dec 31 16:00:00 PST 1995 until Thu Dec 31 15:59:59 PST 2020
adding as trusted cert:
Subject: OU=Class 3 Public Primary Certification Authority, O="VeriSign, Inc.", C=US
Issuer: OU=Class 3 Public Primary Certification Authority, O="VeriSign, Inc.", C=US
Algorithm: RSA; Serial number: 0x70bae41d10d92934b638ca7b03ccbabf
Valid from Sun Jan 28 16:00:00 PST 1996 until Tue Aug 01 16:59:59 PDT 2028
adding as trusted cert:
Subject: OU=Equifax Secure eBusiness CA-2, O=Equifax Secure, C=US
Issuer: OU=Equifax Secure eBusiness CA-2, O=Equifax Secure, C=US
Algorithm: RSA; Serial number: 0x3770cfb5
Valid from Wed Jun 23 05:14:45 PDT 1999 until Sun Jun 23 05:14:45 PDT 2019
adding as trusted cert:
Subject: OU=Equifax Secure Certificate Authority, O=Equifax, C=US
Issuer: OU=Equifax Secure Certificate Authority, O=Equifax, C=US
Algorithm: RSA; Serial number: 0x35def4cf
Valid from Sat Aug 22 09:41:51 PDT 1998 until Wed Aug 22 09:41:51 PDT 2018
adding as trusted cert:
Subject: [email protected], CN=Thawte Personal Freemail CA, OU=Certification Services Division, O=Thawte Consulting, L=Cape Town, ST=Western Cape, C=ZA
Issuer: [email protected], CN=Thawte Personal Freemail CA, OU=Certification Services Division, O=Thawte Consulting, L=Cape Town, ST=Western Cape, C=ZA
Algorithm: RSA; Serial number: 0x0
Valid from Sun Dec 31 16:00:00 PST 1995 until Thu Dec 31 15:59:59 PST 2020
adding as trusted cert:
Subject: CN=Equifax Secure eBusiness CA-1, O=Equifax Secure Inc., C=US
Issuer: CN=Equifax Secure eBusiness CA-1, O=Equifax Secure Inc., C=US
Algorithm: RSA; Serial number: 0x4
Valid from Sun Jun 20 21:00:00 PDT 1999 until Sat Jun 20 21:00:00 PDT 2020
adding as trusted cert:
Subject: [email protected], CN=Thawte Personal Premium CA, OU=Certification Services Division, O=Thawte Consulting, L=Cape Town, ST=Western Cape, C=ZA
Issuer: [email protected], CN=Thawte Personal Premium CA, OU=Certification Services Division, O=Thawte Consulting, L=Cape Town, ST=Western Cape, C=ZA
Algorithm: RSA; Serial number: 0x0
Valid from Sun Dec 31 16:00:00 PST 1995 until Thu Dec 31 15:59:59 PST 2020
adding as trusted cert:
Subject: CN=GTE CyberTrust Root 5, OU="GTE CyberTrust Solutions, Inc.", O=GTE Corporation, C=US
Issuer: CN=GTE CyberTrust Root 5, OU="GTE CyberTrust Solutions, Inc.", O=GTE Corporation, C=US
Algorithm: RSA; Serial number: 0x1b6
Valid from Fri Aug 14 07:50:00 PDT 1998 until Wed Aug 14 16:59:00 PDT 2013
adding as trusted cert:
Subject: OU=Class 1 Public Primary Certification Authority, O="VeriSign, Inc.", C=US
Issuer: OU=Class 1 Public Primary Certification Authority, O="VeriSign, Inc.", C=US
Algorithm: RSA; Serial number: 0xcdba7f56f0dfe4bc54fe22acb372aa55
Valid from Sun Jan 28 16:00:00 PST 1996 until Tue Aug 01 16:59:59 PDT 2028
adding as trusted cert:
Subject: CN=GTE CyberTrust Root, O=GTE Corporation, C=US
Issuer: CN=GTE CyberTrust Root, O=GTE Corporation, C=US
Algorithm: RSA; Serial number: 0x1a3
Valid from Fri Feb 23 15:01:00 PST 1996 until Thu Feb 23 15:59:00 PST 2006
adding as trusted cert:
Subject: CN=Entrust.net Secure Server Certification Authority, OU=(c) 2000 Entrust.net Limited, OU=www.entrust.net/SSL_CPS incorp. by ref. (limits liab.), O=Entrust.net
Issuer: CN=Entrust.net Secure Server Certification Authority, OU=(c) 2000 Entrust.net Limited, OU=www.entrust.net/SSL_CPS incorp. by ref. (limits liab.), O=Entrust.net
Algorithm: RSA; Serial number: 0x389b113c
Valid from Fri Feb 04 09:20:00 PST 2000 until Tue Feb 04 09:50:00 PST 2020
adding as trusted cert:
Subject: OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For authorized use only", OU=Class 3 Public Primary Certification Authority - G2, O="VeriSign, Inc.", C=US
Issuer: OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For authorized use only", OU=Class 3 Public Primary Certification Authority - G2, O="VeriSign, Inc.", C=US
Algorithm: RSA; Serial number: 0x7dd9fe07cfa81eb7107967fba78934c6
Valid from Sun May 17 17:00:00 PDT 1998 until Tue Aug 01 16:59:59 PDT 2028
adding as trusted cert:
Subject: [email protected], CN=Thawte Premium Server CA, OU=Certification Services Division, O=Thawte Consulting cc, L=Cape Town, ST=Western Cape, C=ZA
Issuer: [email protected], CN=Thawte Premium Server CA, OU=Certification Services Division, O=Thawte Consulting cc, L=Cape Town, ST=Western Cape, C=ZA
Algorithm: RSA; Serial number: 0x1
Valid from Wed Jul 31 17:00:00 PDT 1996 until Thu Dec 31 15:59:59 PST 2020
adding as trusted cert:
Subject: OU=Secure Server Certification Authority, O="RSA Data Security, Inc.", C=US
Issuer: OU=Secure Server Certification Authority, O="RSA Data Security, Inc.", C=US
Algorithm: RSA; Serial number: 0x2ad667e4e45fe5e576f3c98195eddc0
Valid from Tue Nov 08 16:00:00 PST 1994 until Thu Jan 07 15:59:59 PST 2010
adding as trusted cert:
Subject: CN=Entrust.net Client Certification Authority, OU=(c) 1999 Entrust.net Limited, OU=www.entrust.net/Client_CA_Info/CPS incorp. by ref. limits liab., O=Entrust.net, C=US
Issuer: CN=Entrust.net Client Certification Authority, OU=(c) 1999 Entrust.net Limited, OU=www.entrust.net/Client_CA_Info/CPS incorp. by ref. limits liab., O=Entrust.net, C=US
Algorithm: RSA; Serial number: 0x380391ee
Valid from Tue Oct 12 12:24:30 PDT 1999 until Sat Oct 12 12:54:30 PDT 2019
adding as trusted cert:
Subject: CN=Entrust.net Client Certification Authority, OU=(c) 2000 Entrust.net Limited, OU=www.entrust.net/GCCA_CPS incorp. by ref. (limits liab.), O=Entrust.net
Issuer: CN=Entrust.net Client Certification Authority, OU=(c) 2000 Entrust.net Limited, OU=www.entrust.net/GCCA_CPS incorp. by ref. (limits liab.), O=Entrust.net
Algorithm: RSA; Serial number: 0x389ef6e4
Valid from Mon Feb 07 08:16:40 PST 2000 until Fri Feb 07 08:46:40 PST 2020
adding as trusted cert:
Subject: OU=Class 2 Public Primary Certification Authority, O="VeriSign, Inc.", C=US
Issuer: OU=Class 2 Public Primary Certification Authority, O="VeriSign, Inc.", C=US
Algorithm: RSA; Serial number: 0x2d1bfc4a178da391ebe7fff58b45be0b
Valid from Sun Jan 28 16:00:00 PST 1996 until Tue Aug 01 16:59:59 PDT 2028
adding as trusted cert:
Subject: CN=VeriSign Class 2 Public Primary Certification Authority - G3, OU="(c) 1999 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US
Issuer: CN=VeriSign Class 2 Public Primary Certification Authority - G3, OU="(c) 1999 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US
Algorithm: RSA; Serial number: 0x6170cb498c5f984529e7b0a6d9505b7a
Valid from Thu Sep 30 17:00:00 PDT 1999 until Wed Jul 16 16:59:59 PDT 2036
adding as trusted cert:
Subject: CN=GTE CyberTrust Global Root, OU="GTE CyberTrust Solutions, Inc.", O=GTE Corporation, C=US
Issuer: CN=GTE CyberTrust Global Root, OU="GTE CyberTrust Solutions, Inc.", O=GTE Corporation, C=US
Algorithm: RSA; Serial number: 0x1a5
Valid from Wed Aug 12 17:29:00 PDT 1998 until Mon Aug 13 16:59:00 PDT 2018
adding as trusted cert:
Subject: [email protected], CN=Thawte Server CA, OU=Certification Services Division, O=Thawte Consulting cc, L=Cape Town, ST=Western Cape, C=ZA
Issuer: [email protected], CN=Thawte Server CA, OU=Certification Services Division, O=Thawte Consulting cc, L=Cape Town, ST=Western Cape, C=ZA
Algorithm: RSA; Serial number: 0x1
Valid from Wed Jul 31 17:00:00 PDT 1996 until Thu Dec 31 15:59:59 PST 2020
adding as trusted cert:
Subject: CN=GeoTrust Global CA, O=GeoTrust Inc., C=US
Issuer: CN=GeoTrust Global CA, O=GeoTrust Inc., C=US
Algorithm: RSA; Serial number: 0x23456
Valid from Mon May 20 21:00:00 PDT 2002 until Fri May 20 21:00:00 PDT 2022
adding as trusted cert:
Subject: CN=Entrust.net Certification Authority (2048), OU=(c) 1999 Entrust.net Limited, OU=www.entrust.net/CPS_2048 incorp. by ref. (limits liab.), O=Entrust.net
Issuer: CN=Entrust.net Certification Authority (2048), OU=(c) 1999 Entrust.net Limited, OU=www.entrust.net/CPS_2048 incorp. by ref. (limits liab.), O=Entrust.net
Algorithm: RSA; Serial number: 0x3863b966
Valid from Fri Dec 24 09:50:51 PST 1999 until Tue Dec 24 10:20:51 PST 2019
adding as trusted cert:
Subject: CN=Equifax Secure Global eBusiness CA-1, O=Equifax Secure Inc., C=US
Issuer: CN=Equifax Secure Global eBusiness CA-1, O=Equifax Secure Inc., C=US
Algorithm: RSA; Serial number: 0x1
Valid from Sun Jun 20 21:00:00 PDT 1999 until Sat Jun 20 21:00:00 PDT 2020
adding as trusted cert:
Subject: OU=Go Daddy Class 2 Certification Authority, O="The Go Daddy Group, Inc.", C=US
Issuer: OU=Go Daddy Class 2 Certification Authority, O="The Go Daddy Group, Inc.", C=US
Algorithm: RSA; Serial number: 0x0
Valid from Tue Jun 29 10:06:20 PDT 2004 until Thu Jun 29 10:06:20 PDT 2034
adding as trusted cert:
Subject: CN=VeriSign Class 1 Public Primary Certification Authority - G3, OU="(c) 1999 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US
Issuer: CN=VeriSign Class 1 Public Primary Certification Authority - G3, OU="(c) 1999 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US
Algorithm: RSA; Serial number: 0x8b5b75568454850b00cfaf3848ceb1a4
Valid from Thu Sep 30 17:00:00 PDT 1999 until Wed Jul 16 16:59:59 PDT 2036
adding as trusted cert:
Subject: OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For authorized use only", OU=Class 2 Public Primary Certification Authority - G2, O="VeriSign, Inc.", C=US
Issuer: OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For authorized use only", OU=Class 2 Public Primary Certification Authority - G2, O="VeriSign, Inc.", C=US
Algorithm: RSA; Serial number: 0xb92f60cc889fa17a4609b85b706c8aaf
Valid from Sun May 17 17:00:00 PDT 1998 until Tue Aug 01 16:59:59 PDT 2028
adding as trusted cert:
Subject: OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For authorized use only", OU=Class 1 Public Primary Certification Authority - G2, O="VeriSign, Inc.", C=US
Issuer: OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For authorized use only", OU=Class 1 Public Primary Certification Authority - G2, O="VeriSign, Inc.", C=US
Algorithm: RSA; Serial number: 0x4cc7eaaa983e71d39310f83d3a899192
Valid from Sun May 17 17:00:00 PDT 1998 until Tue Aug 01 16:59:59 PDT 2028
trigger seeding of SecureRandom
done seeding SecureRandom
main, setSoTimeout(50000) called
TIMEOUT=50000
%% No cached client session
*** ClientHello, TLSv1
RandomCookie: GMT: 1123703368 bytes = { 11, 7, 242, 147, 134, 10, 57, 192, 137, 131, 191, 249, 253, 146, 232, 223, 146, 195, 53, 255, 121, 236, 182, 158, 191, 94, 156, 190 }
Session ID: {}
Cipher Suites: [SSL_RSA_WITH_RC4_128_MD5, SSL_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_DES_CBC_SHA, SSL_DHE_RSA_WITH_DES_CBC_SHA, SSL_DHE_DSS_WITH_DES_CBC_SHA, SSL_RSA_EXPORT_WITH_RC4_40_MD5, SSL_RSA_EXPORT_WITH_DES40_CBC_SHA, SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA, SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA]
Compression Methods: { 0 }
main, WRITE: TLSv1 Handshake, length = 73
main, WRITE: SSLv2 client hello message, length = 98
main, READ: TLSv1 Handshake, length = 873
*** ServerHello, TLSv1
RandomCookie: GMT: 1123703296 bytes = { 123, 165, 102, 102, 169, 196, 229, 241, 3, 49, 81, 239, 83, 155, 209, 243, 236, 229, 18, 193, 228, 104, 27, 152, 232, 193, 173, 11 }
Session ID: {147, 24, 0, 0, 22, 29, 124, 158, 177, 166, 96, 36, 217, 32, 191, 41, 36, 217, 54, 244, 11, 56, 214, 139, 133, 140, 38, 132, 157, 77, 87, 77}
Cipher Suite: SSL_RSA_WITH_RC4_128_MD5
Compression Method: 0
%% Created: [Session-1, SSL_RSA_WITH_RC4_128_MD5]
** SSL_RSA_WITH_RC4_128_MD5
*** Certificate chain
chain [0] = [
Version: V3
Subject: CN=www.just-in-time-eft-paymap.com, OU=Paymap, O=First Data Corporation., L=San Francisco, ST=California, C=US
Signature Algorithm: SHA1withRSA, OID = 1.2.840.113549.1.1.5
Key: Sun RSA public key, 1024 bits
modulus: 115897801846480906504507305240934762652258285705294305856746227593079520228602278416768070978663757452626836382370415992468189745643687252249588163510925353035555192020212360325664657305599855674966873189987712512397233103225326014387972568754281141553272745093478026229567341632738641376167448499163118598699
public exponent: 65537
Validity: [From: Mon Sep 12 11:37:51 PDT 2005,
               To: Sun Nov 12 11:37:51 PST 2006]
Issuer: OU=Equifax Secure Certificate Authority, O=Equifax, C=US
SerialNumber: [    057aa7]
Certificate Extensions: 5
[1]: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: FC 76 D2 8C C3 DE 0D 8F EA 32 26 60 83 C9 8B 9C .v.......2&`....
0010: C6 E6 BB 57 ...W
[2]: ObjectId: 2.5.29.35 Criticality=false
AuthorityKeyIdentifier [
KeyIdentifier [
0000: 48 E6 68 F9 2B D2 B2 95 D7 47 D8 23 20 10 4F 33 H.h.+....G.# .O3
0010: 98 90 9F D4 ....
[3]: ObjectId: 2.5.29.31 Criticality=false
CRLDistributionPoints [
[DistributionPoint:
[URIName: http://crl.geotrust.com/crls/secureca.crl]
[4]: ObjectId: 2.5.29.37 Criticality=false
ExtendedKeyUsages [
[1.3.6.1.5.5.7.3.1, 1.3.6.1.5.5.7.3.2]]
[5]: ObjectId: 2.5.29.15 Criticality=true
KeyUsage [
DigitalSignature
Non_repudiation
Key_Encipherment
Data_Encipherment
Algorithm: [SHA1withRSA]
Signature:
0000: 44 D7 B0 69 BF B0 AA 4D 5A 17 70 9C 37 BA 61 A2 D..i...MZ.p.7.a.
0010: 57 B4 34 85 6D 59 1F 82 72 34 9B 92 7D BD DF 27 W.4.mY..r4.....'
0020: CE 97 E3 CA AE 23 5D 85 3C 1A C6 19 D1 49 C2 3F .....#].<....I.?
0030: C6 E2 7E 97 8D 63 94 1E 04 AC 9F 5F 37 08 2A 96 .....c....._7.*.
0040: 1A 47 D1 9D 69 0C 71 6A F3 74 1C FF 7D 20 E1 CA .G..i.qj.t... ..
0050: 75 D0 45 84 2E 11 3C DD D4 73 25 38 76 27 E0 73 u.E...<..s%8v'.s
0060: 70 AC 70 0F A5 E3 5B 9D 7E 0E AB 6A 79 07 18 38 p.p...[....jy..8
0070: 5B A1 63 A2 89 8C 96 A1 50 36 4C D2 C6 D5 27 25 [.c.....P6L...'%
Found trusted certificate:
Version: V3
Subject: OU=Equifax Secure Certificate Authority, O=Equifax, C=US
Signature Algorithm: SHA1withRSA, OID = 1.2.840.113549.1.1.5
Key: Sun RSA public key, 1024 bits
modulus: 135786214035069526348186531221551781468391756233528066061569654028671100866720352830303278016129003918213826297308054231261658522889438712013757624116391437358730449661353175673177742307421061340003741057138887918110217006515773038453829253517076741780039735595086881329494037450587568122088113584549069375417
public exponent: 65537
Validity: [From: Sat Aug 22 09:41:51 PDT 1998,
               To: Wed Aug 22 09:41:51 PDT 2018]
Issuer: OU=Equifax Secure Certificate Authority, O=Equifax, C=US
SerialNumber: [    35def4cf]
Certificate Extensions: 7
[1]: ObjectId: 1.2.840.113533.7.65.0 Criticality=false
Extension unknown: DER encoded OCTET string =
0000: 04 0D 30 0B 1B 05 56 33 2E 30 63 03 02 06 C0 ..0...V3.0c....
[2]: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: 48 E6 68 F9 2B D2 B2 95 D7 47 D8 23 20 10 4F 33 H.h.+....G.# .O3
0010: 98 90 9F D4 ....
[3]: ObjectId: 2.5.29.35 Criticality=false
AuthorityKeyIdentifier [
KeyIdentifier [
0000: 48 E6 68 F9 2B D2 B2 95 D7 47 D8 23 20 10 4F 33 H.h.+....G.# .O3
0010: 98 90 9F D4 ....
[4]: ObjectId: 2.5.29.31 Criticality=false
CRLDistributionPoints [
[DistributionPoint:
[CN=CRL1, OU=Equifax Secure Certificate Authority, O=Equifax, C=US]
[5]: ObjectId: 2.5.29.15 Criticality=false
KeyUsage [
Key_CertSign
Crl_Sign
[6]: ObjectId: 2.5.29.16 Criticality=false
PrivateKeyUsage: [
To: Wed Aug 22 09:41:51 PDT 2018]
[7]: ObjectId: 2.5.29.19 Criticality=false
BasicConstraints:[
CA:true
PathLen:2147483647
Algorithm: [SHA1withRSA]
Signature:
0000: 58 CE 29 EA FC F7 DE B5 CE 02 B9 17 B5 85 D1 B9 X.).............
0010: E3 E0 95 CC 25 31 0D 00 A6 92 6E 7F B6 92 63 9E ....%1....n...c.
0020: 50 95 D1 9A 6F E4 11 DE 63 85 6E 98 EE A8 FF 5A P...o...c.n....Z
0030: C8 D3 55 B2 66 71 57 DE C0 21 EB 3D 2A A7 23 49 ..U.fqW..!.=*.#I
0040: 01 04 86 42 7B FC EE 7F A2 16 52 B5 67 67 D3 40 ...B......R.gg.@
0050: DB 3B 26 58 B2 28 77 3D AE 14 77 61 D6 FA 2A 66 .;&X.(w=..wa..*f
0060: 27 A0 0D FA A7 73 5C EA 70 F1 94 21 65 44 5F FA '....s\.p..!eD_.
0070: FC EF 29 68 A9 A2 87 79 EF 79 EF 4F AC 07 77 38 ..)h...y.y.O..w8
*** ServerHelloDone
*** ClientKeyExchange, RSA PreMasterSecret, TLSv1
Random Secret: { 3, 1, 82, 2, 69, 241, 210, 36, 175, 168, 76, 86, 170, 3, 158, 52, 89, 146, 84, 210, 223, 113, 212, 231, 129, 100, 177, 125, 116, 31, 97, 233, 150, 162, 161, 51, 168, 189, 14, 47, 83, 27, 67, 252, 172, 191, 102, 39 }
main, WRITE: TLSv1 Handshake, length = 134
SESSION KEYGEN:
PreMaster Secret:
0000: 03 01 52 02 45 F1 D2 24 AF A8 4C 56 AA 03 9E 34 ..R.E..$..LV...4
0010: 59 92 54 D2 DF 71 D4 E7 81 64 B1 7D 74 1F 61 E9 Y.T..q...d..t.a.
0020: 96 A2 A1 33 A8 BD 0E 2F 53 1B 43 FC AC BF 66 27 ...3.../S.C...f'
CONNECTION KEYGEN:
Client Nonce:
0000: 43 FA 5A 48 0B 07 F2 93 86 0A 39 C0 89 83 BF F9 C.ZH......9.....
0010: FD 92 E8 DF 92 C3 35 FF 79 EC B6 9E BF 5E 9C BE ......5.y....^..
Server Nonce:
0000: 43 FA 5A 00 7B A5 66 66 A9 C4 E5 F1 03 31 51 EF C.Z...ff.....1Q.
0010: 53 9B D1 F3 EC E5 12 C1 E4 68 1B 98 E8 C1 AD 0B S........h......
Master Secret:
0000: 10 47 C2 16 13 58 4B 50 D3 D6 34 05 C8 C9 11 29 .G...XKP..4....)
0010: AD 90 0D 8F 9B BD C8 C1 FC CD BC 26 ED FB 26 84 ...........&..&.
0020: 04 0B 94 BC D2 4D 7D 71 E0 1E 08 10 59 38 B5 4E .....M.q....Y8.N
Client MAC write Secret:
0000: A5 66 C1 48 0E F1 18 2B 2B 7A F7 9B A4 6C D7 FA .f.H...++z...l..
Server MAC write Secret:
0000: 3B F5 04 FA AC 9C D7 ED 2E E7 36 44 80 FF 11 E2 ;.........6D....
Client write key:
0000: 7B 9F 56 A1 FC 3D BD 31 25 27 91 BB D0 66 66 0B ..V..=.1%'...ff.
Server write key:
0000: 2B 45 E2 19 E8 C8 61 5B 84 B8 94 76 A1 B4 9C 6E +E....a[...v...n
... no IV for cipher
main, WRITE: TLSv1 Change Cipher Spec, length = 1
*** Finished
verify_data: { 110, 253, 95, 109, 150, 89, 93, 140, 108, 186, 172, 188 }
main, WRITE: TLSv1 Handshake, length = 32
main, READ: TLSv1 Change Cipher Spec, length = 1
main, READ: TLSv1 Handshake, length = 32
*** Finished
verify_data: { 70, 219, 18, 202, 105, 203, 83, 220, 151, 174, 102, 125 }
%% Cached client session: [Session-1, SSL_RSA_WITH_RC4_128_MD5]
main, setSoTimeout(50000) called
main, WRITE: TLSv1 Application Data, length = 96
main, setSoTimeout(50000) called
main, READ: TLSv1 Handshake, length = 20
*** HelloRequest (empty)
%% Client cached [Session-1, SSL_RSA_WITH_RC4_128_MD5]
%% Try resuming [Session-1, SSL_RSA_WITH_RC4_128_MD5] from port 1130
*** ClientHello, TLSv1
RandomCookie: GMT: 1123703368 bytes = { 242, 6, 117, 127, 243, 197, 134, 82, 139, 54, 241, 243, 132, 22, 63, 136, 4, 180, 225, 8, 159, 55, 182, 105, 133, 226, 213, 167 }
Session ID: {147, 24, 0, 0, 22, 29, 124, 158, 177, 166, 96, 36, 217, 32, 191, 41, 36, 217, 54, 244, 11, 56, 214, 139, 133, 140, 38, 132, 157, 77, 87, 77}
Cipher Suites: [SSL_RSA_WITH_RC4_128_MD5, SSL_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_DES_CBC_SHA, SSL_DHE_RSA_WITH_DES_CBC_SHA, SSL_DHE_DSS_WITH_DES_CBC_SHA, SSL_RSA_EXPORT_WITH_RC4_40_MD5, SSL_RSA_EXPORT_WITH_DES40_CBC_SHA, SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA, SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA]
Compression Methods: { 0 }
main, WRITE: TLSv1 Handshake, length = 121
main, READ: TLSv1 Handshake, length = 11432
*** ServerHello, TLSv1
RandomCookie: GMT: 1123703296 bytes = { 168, 158, 224, 186, 230, 77, 9, 24, 237, 106, 203, 158, 176, 252, 249, 167, 73, 173, 69, 178, 115, 34, 96, 179, 191, 230, 178, 160 }
Session ID: {3, 27, 0, 0, 51, 252, 181, 131, 214, 28, 220, 247, 154, 175, 51, 237, 76, 111, 88, 78, 28, 105, 106, 114, 42, 51, 53, 144, 178, 93, 245, 127}
Cipher Suite: SSL_RSA_WITH_RC4_128_MD5
Compression Method: 0
%% Created: [Session-2, SSL_RSA_WITH_RC4_128_MD5]
** SSL_RSA_WITH_RC4_128_MD5
*** Certificate chain
chain [0] = [
Version: V3
Subject: CN=www.just-in-time-eft-paymap.com, OU=Paymap, O=First Data Corporation., L=San Francisco, ST=California, C=US
Signature Algorithm: SHA1withRSA, OID = 1.2.840.113549.1.1.5
Key: Sun RSA public key, 1024 bits
modulus: 115897801846480906504507305240934762652258285705294305856746227593079520228602278416768070978663757452626836382370415992468189745643687252249588163510925353035555192020212360325664657305599855674966873189987712512397233103225326014387972568754281141553272745093478026229567341632738641376167448499163118598699
public exponent: 65537
Validity: [From: Mon Sep 12 11:37:51 PDT 2005,
               To: Sun Nov 12 11:37:51 PST 2006]
Issuer: OU=Equifax Secure Certificate Authority, O=Equifax, C=US
SerialNumber: [    057aa7]
Certificate Extensions: 5
[1]: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: FC 76 D2 8C C3 DE 0D 8F EA 32 26 60 83 C9 8B 9C .v.......2&`....
0010: C6 E6 BB 57 ...W
[2]: ObjectId: 2.5.29.35 Criticality=false
AuthorityKeyIdentifier [
KeyIdentifier [
0000: 48 E6 68 F9 2B D2 B2 95 D7 47 D8 23 20 10 4F 33 H.h.+....G.# .O3
0010: 98 90 9F D4 ....
[3]: ObjectId: 2.5.29.31 Criticality=false
CRLDistributionPoints [
[DistributionPoint:
[URIName: http://crl.geotrust.com/crls/secureca.crl]
[4]: ObjectId: 2.5.29.37 Criticality=false
ExtendedKeyUsages [
[1.3.6.1.5.5.7.3.1, 1.3.6.1.5.5.7.3.2]]
[5]: ObjectId: 2.5.29.15 Criticality=true
KeyUsage [
DigitalSignature
Non_repudiation
Key_Encipherment
Data_Encipherment
Algorithm: [SHA1withRSA]
Signature:
0000: 44 D7 B0 69 BF B0 AA 4D 5A 17 70 9C 37 BA 61 A2 D..i...MZ.p.7.a.
0010: 57 B4 34 85 6D 59 1F 82 72 34 9B 92 7D BD DF 27 W.4.mY..r4.....'
0020: CE 97 E3 CA AE 23 5D 85 3C 1A C6 19 D1 49 C2 3F .....#].<....I.?
0030: C6 E2 7E 97 8D 63 94 1E 04 AC 9F 5F 37 08 2A 96 .....c....._7.*.
0040: 1A 47 D1 9D 69 0C 71 6A F3 74 1C FF 7D 20 E1 CA .G..i.qj.t... ..
0050: 75 D0 45 84 2E 11 3C DD D4 73 25 38 76 27 E0 73 u.E...<..s%8v'.s
0060: 70 AC 70 0F A5 E3 5B 9D 7E 0E AB 6A 79 07 18 38 p.p...[....jy..8
0070: 5B A1 63 A2 89 8C 96 A1 50 36 4C D2 C6 D5 27 25 [.c.....P6L...'%
Found trusted certificate:
Version: V3
Subject: OU=Equifax Secure Certificate Authority, O=Equifax, C=US
Signature Algorithm: SHA1withRSA, OID = 1.2.840.113549.1.1.5
Key: Sun RSA public key, 1024 bits
modulus: 135786214035069526348186531221551781468391756233528066061569654028671100866720352830303278016129003918213826297308054231261658522889438712013757624116391437358730449661353175673177742307421061340003741057138887918110217006515773038453829253517076741780039735595086881329494037450587568122088113584549069375417
public exponent: 65537
Validity: [From: Sat Aug 22 09:41:51 PDT 1998,
               To: Wed Aug 22 09:41:51 PDT 2018]
Issuer: OU=Equifax Secure Certificate Authority, O=Equifax, C=US
SerialNumber: [    35def4cf]
Certificate Extensions: 7
[1]: ObjectId: 1.2.840.113533.7.65.0 Criticality=false
Extension unknown: DER encoded OCTET string =
0000: 04 0D 30 0B 1B 05 56 33 2E 30 63 03 02 06 C0 ..0...V3.0c....
[2]: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: 48 E6 68 F9 2B D2 B2 95 D7 47 D8 23 20 10 4F 33 H.h.+....G.# .O3
0010: 98 90 9F D4 ....
[3]: ObjectId: 2.5.29.35 Criticality=false
AuthorityKeyIdentifier [
KeyIdentifier [
0000: 48 E6 68 F9 2B D2 B2 95 D7 47 D8 23 20 10 4F 33 H.h.+....G.# .O3
0010: 98 90 9F D4 ....
[4]: ObjectId: 2.5.29.31 Criticality=false
CRLDistributionPoints [
[DistributionPoint:
[CN=CRL1, OU=Equifax Secure Certificate Authority, O=Equifax, C=US]
[5]: ObjectId: 2.5.29.15 Criticality=false
KeyUsage [
Key_CertSign
Crl_Sign
[6]: ObjectId: 2.5.29.16 Criticality=false
PrivateKeyUsage: [
To: Wed Aug 22 09:41:51 PDT 2018]
[7]: ObjectId: 2.5.29.19 Criticality=false
BasicConstraints:[
CA:true
PathLen:2147483647
Algorithm: [SHA1withRSA]
Signature:
0000: 58 CE 29 EA FC F7 DE B5 CE 02 B9 17 B5 85 D1 B9 X.).............
0010: E3 E0 95 CC 25 31 0D 00 A6 92 6E 7F B6 92 63 9E ....%1....n...c.
0020: 50 95 D1 9A 6F E4 11 DE 63 85 6E 98 EE A8 FF 5A P...o...c.n....Z
0030: C8 D3 55 B2 66 71 57 DE C0 21 EB 3D 2A A7 23 49 ..U.fqW..!.=*.#I
0040: 01 04 86 42 7B FC EE 7F A2 16 52 B5 67 67 D3 40 ...B......R.gg.@
0050: DB 3B 26 58 B2 28 77 3D AE 14 77 61 D6 FA 2A 66 .;&X.(w=..wa..*f
0060: 27 A0 0D FA A7 73 5C EA 70 F1 94 21 65 44 5F FA '....s\.p..!eD_.
0070: FC EF 29 68 A9 A2 87 79 EF 79 EF 4F AC 07 77 38 ..)h...y.y.O..w8
*** CertificateRequest
Cert Types: RSA,
Cert Authorities:
<OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For authorized use only", OU=Class 1 Public Primary Certification Authority - G2, O="VeriSign, Inc.", C=US>
<CN=Sonera Class1 CA, O=Sonera, C=FI>
<OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For authorized use only", OU=Class 4 Public Primary Certification Authority - G2, O="VeriSign, Inc.", C=US>
<CN=Staat der Nederlanden Root CA, O=Staat der Nederlanden, C=NL>
<CN=VeriSign Class 3

I have the same problem. I�m turning crazy working with certificates in mutual athetication!!!
If someone has the solution to this problem, send a repy or at [email protected]
Thanks in advance

DLL's - Websphere MQ and Java Client

I am trying to post a message to Websphere MQ by using JMS Admin and Webspehre Application server. I have configured JMS Admin for registering the JNDI name with app server. I am using a standalone java (makes IIOP call) Application for posting the message. When I am running the java client in the machine where the MQ is installed the application runs fine. But, when I use it in a different machine, It is informing that variour DLLs are absent. Please let me know if all the Websphere MQ dlls need to be placed in the Stand alone java client machine.
Thanks a lot in advance.
Arun

If you are using the JMSAdmin from IBM in the ma88 support pack and getting this error, then check to see if the following .dll files (or .dll files with similar names) are present in your PATH environment variable:
mqjbdf01.dll
mqjbnd04.dll
MQXAi01.dll
The above dlls are required for the MQSeries jar files to make native calls to MQSeries server.
Please check and this should solve your problem.

Related to Network program using Java Client and C server

I am little bit experience in java technology. I need an urgent help as I have to submit a document related to C server and Java client. But while searching in net i cant get a proper guidance for C server as many errors thrown in sys/socket.h and other new header files. Can any one help me out for giving source code for C Server. so that i can further involve in that document. Please help me out. i am really helpless by the way the C server thrown error. after finishing that C server only i can concentrate on Java client...

Hai Josah,
Thanks for your reply.. I have gone through many sockets server program in C but the real proble is the header file they include like
socket.h and in.h etc.. they also provide these header files but if we compile in turboC they inturn require some other header files. I dont get the full hierarchy of C server program. I found some help in Java programming Archive about C Server and java client. As i am new to C i cant get the full header files for the server.c if i complete taht only i can proceed to java client. If u can redirect me for any good C sites also i can be thankful for u forever..please

Need to communicate c server on linux & java client on windows

Hi!! I am new to socket programing in both C and Java.
From let I downloaded some client server example for c and java and tried that to link !! (I allways learn this way , and I need to do that little urget )
though cient server in linux is working perfectly fine and same for java. But problem is when I tried to communicate C server on linux and java client on windows, I end up with getting some junk characters. Though they are connected successfully.
Here goes code for java client:
package whatever;
import java.io.*;
import java.net.*;
public class Requester{
     Socket requestSocket;
     ObjectOutputStream out;
     ObjectInputStream in;
     String message;
     Requester(){}
     void run()
          try{
               //1. creating a socket to connect to the server
               requestSocket = new Socket("192.168.72.128", 2006);
               System.out.println("Connected to localhost in port 2004");
               //2. get Input and Output streams
               out = new ObjectOutputStream(requestSocket.getOutputStream());
               out.flush();
               in = new ObjectInputStream(requestSocket.getInputStream());
               System.out.println("above do");
               //3: Communicating with the server
               do{
                    try{
                         System.out.println("in do");
                         //message = (String)in.readObject();
                         System.out.println("in try");
                         //System.out.println("server>" + message);
                         System.out.println("server>" + "message");
                         sendMessage("Hi my server");
                         message = "bye";
                         sendMessage(message);
                         System.out.println("try completed");
                    catch(Exception e){
                         e.printStackTrace();
               }while(!message.equals("bye"));
          catch(UnknownHostException unknownHost){
               System.err.println("You are trying to connect to an unknown host!");
          catch(IOException ioException){
               ioException.printStackTrace();
          finally{
               //4: Closing connection
               try{
                    in.close();
                    out.close();
                    requestSocket.close();
               catch(IOException ioException){
                    ioException.printStackTrace();
     void sendMessage(String msg)
          try{
               String stringToConvert= "hello world";
               byte[] theByteArray = stringToConvert.getBytes();
                  System.out.println(theByteArray.length);
               out.writeObject(theByteArray);
               out.flush();
               System.out.println("client>" + msg);
          catch(IOException ioException){
               ioException.printStackTrace();
          catch(Exception ex){
               ex.printStackTrace();
     public static void main(String args[])
          Requester client = new Requester();
          client.run();
And for C server
/ server
    #include <stdio.h>
        #include <sys/socket.h>
        #include <arpa/inet.h>
        #include <stdlib.h>
        #include <string.h>
        #include <unistd.h>
        #include <netinet/in.h>
        #define MAXPENDING 5    /* Max connection requests */
        #define BUFFSIZE 32
        void Die(char *mess) { perror(mess); exit(1); }
    void HandleClient(int sock) {
            char buffer[BUFFSIZE];
            int received = -1;
            /* Receive message */
            if ((received = recv(sock, buffer, BUFFSIZE, 0)) < 0) {
                Die("Failed to receive initial bytes from client");
            /* Send bytes and check for more incoming data in loop */
            while (received > 0) {
            /* Send back received data */
                if (send(sock, buffer, received, 0) != received) {
                    Die("Failed to send bytes to client");
//            fprintf("%s",buffer);
            fprintf(stdout, "message Recieved: %s\n", buffer);
                //Die("was not able to echo socket message");
            /* Check for more data */
                if ((received = recv(sock, buffer, BUFFSIZE, 0)) < 0) {
                    Die("Failed to receive additional bytes from client");
            close(sock);
    //     A TCP ECHO SERVER
    int main(int argc, char *argv[]) {
            int serversock, clientsock;
                struct sockaddr_in echoserver, echoclient;
                if (argc != 2) {
                  fprintf(stderr, "USAGE: echoserver <port>\n");
                exit(1);
            /* Create the TCP socket */
                if ((serversock = socket(PF_INET, SOCK_STREAM, IPPROTO_TCP)) < 0) {
                  Die("Failed to create socket");
            /* Construct the server sockaddr_in structure */
                memset(&echoserver, 0, sizeof(echoserver));      /* Clear struct */
                echoserver.sin_family = AF_INET;                  /* Internet/IP */
                echoserver.sin_addr.s_addr = htonl(INADDR_ANY); /* Incoming addr */
                echoserver.sin_port = htons(atoi(argv[1]));      /* server port */
    // A TCP ECHO SERVER ENDS
    // A TCP ECHO SERVER BINDING AND LISTNING
/* Bind the server socket */
              if (bind(serversock, (struct sockaddr *) &echoserver, sizeof(echoserver)) < 0) {
                    Die("Failed to bind the server socket");
          /* Listen on the server socket */
              if (listen(serversock, MAXPENDING) < 0) {
              Die("Failed to listen on server socket");
    // A TCP ECHO SERVER BINDING AND LISTNING
    // SOCKET FACTORY
/* Run until cancelled */
            while (1) {
                    unsigned int clientlen = sizeof(echoclient);
                      /* Wait for client connection */
                    if ((clientsock =
                      accept(serversock, (struct sockaddr *) &echoclient, &clientlen)) < 0) {
                        Die("Failed to accept client connection");
                      fprintf(stdout, "Client connected: %s\n", inet_ntoa(echoclient.sin_addr));
                      HandleClient(clientsock);
    // SOCKET FACTORY ENDSI know that it is not C forum but I found no better place to post it
Thanks

kajbj wrote:
ManMohanVyas wrote:
hii!! just trying to make it a little more explinatory
1) what I am trying to accomplish by the above code is: - just need to echo/print from the Server , message send by the Client. I know code is not that good but should be able to perform this basic operation( according to me ).You are wrong. I told you that it won't work as long as you are using ObjectOutputStream and ObjectInputStream. You shouldn't write objects.
2) Message sent by the client is "hello world"(hard coded).No, it's not. You are writing a serialized byte array.
3) what I am getting at the client end is "*message recieved: ur*" (before that It shows the Ip of client machine)
It should print "hello world ".See above.
You are having a problem, and I have told you what the problem is.hey I dont know what went wrong but . I posted all this just next to my first post ...before you posted !!
And hard coded byte array includes "hello world"...may be I am not able to explain properly.

Java clients and IUserPrincipal class not working for authentication

I'm developing a Java client which talks to EJBs on the iAS server via
iiop.
I've already developed EJBs, and they work fine. I'm trying to do user
authentication per the examples in the Rich Client section.
Here are the steps I've taken:
1. I've created a class (achp.security.AchpPrincipal) which implements
com.netscape.ejb.client.IUserPrincipal.
2. I've added the class to the initial context via the following line:
env.put("com.netscape.ejb.client.PrincipalClass",
"achp.security.AchpPrincipal");
3. I do a home lookup with the above initial context when the
application starts, create a bean, and then invoke a method on the bean.
When I do the home lookup, according to the manual, my AchpPrincipal
class should be instantiated (which brings up a login window which then
records username and password for future use).
This never happens. The AchpPrincipal class is never instantiated,
although the home lookup occurs successfully and the bean method call is
also performed successfully.
I'm running server on my Win2K desktop, with SP3. And, of course, I've
properly installed the CXS server (as indicated by the fact that I can
communicate with the EJBs at all though the Java client).
Any help would be appreciated.
Thanks,
Douglas Bullard
Multnomah County ISD

I'm developing a Java client which talks to EJBs on the iAS server via
iiop.
I've already developed EJBs, and they work fine. I'm trying to do user
authentication per the examples in the Rich Client section.
Here are the steps I've taken:
1. I've created a class (achp.security.AchpPrincipal) which implements
com.netscape.ejb.client.IUserPrincipal.
2. I've added the class to the initial context via the following line:
env.put("com.netscape.ejb.client.PrincipalClass",
"achp.security.AchpPrincipal");
3. I do a home lookup with the above initial context when the
application starts, create a bean, and then invoke a method on the bean.
When I do the home lookup, according to the manual, my AchpPrincipal
class should be instantiated (which brings up a login window which then
records username and password for future use).
This never happens. The AchpPrincipal class is never instantiated,
although the home lookup occurs successfully and the bean method call is
also performed successfully.
I'm running server on my Win2K desktop, with SP3. And, of course, I've
properly installed the CXS server (as indicated by the fact that I can
communicate with the EJBs at all though the Java client).
Any help would be appreciated.
Thanks,
Douglas Bullard
Multnomah County ISD

Client authentication doesnt work between 1.0.3 and 1.4

Hi!
Has anyone else experienced the following problem?
I programmed an client-server-application using an SSL connection.
It works well if client and server run on the same java version (JRE 1.3
with JSSE 1.0.3 or JRE 1.4). It also works well when server is running on
JRE 1.4 and client on 1.3 with 1.0.3.
But when I run the client with JRE 1.4 and the server with JDK 1.3 and JSSE
1.0.3 the connection fails with the following exception:
javax.net.ssl.SSLHandshakeException: Received fatal alert: bad_certificate
Studiing the SSL debug outputs it occured to me that the client did not send
his certificate as he was supposed to be because setNeedClientAuth was set
to true.
So i set NeedClientAuth to false and everything worked OK.
Any ideas about how I can get client authentication working?
If debug output is useful I will post it too.
Thanks in advance.
CU, Florian

Hi!
The described behaviour only shows up with Version 1.4.1 and 1.4.1_01. No problems with 1.4.0_03.
Seems to be a bug in 1.4.1.
CU, Florian

Non Java Webservice client Authentication

I see in the Weblogic docs many examples of Java webservice clients. Including
one that passes a user id and password through the getXXXPort(userid, password)
call for authenticating the user at runtime. My question is, can a non Java webservice
client authenticate itself in somewhat the same manor? A non Java client wouldn't
have the client jar file available containing the stubs and all.
If someone has a code snippet they could send me it would be most appreciated.
Thanks,
Craig Lindley

Hi Craig,
An partial example using .NET is attached; in this environment you need
to use their NetworkCredential class.
Hope this helps,
Bruce
craig lindley wrote:
>
I see in the Weblogic docs many examples of Java webservice clients. Including
one that passes a user id and password through the getXXXPort(userid, password)
call for authenticating the user at runtime. My question is, can a non Java webservice
client authenticate itself in somewhat the same manor? A non Java client wouldn't
have the client jar file available containing the stubs and all.
If someone has a code snippet they could send me it would be most appreciated.
Thanks,
Craig Lindleyusing System;
using System.Net;
namespace SecurityBasicClient
class AuthClient
[STAThread]
static void Main(string[] args)
SoapInteropBaseService ws = new SoapInteropBaseService();
ws.Url = "http://webservice.bea.com:7001/base/SoapInteropBaseService";
Console.Write("User:");
string strUser = Console.ReadLine();
Console.Write("Password:");
string strPassword = Console.ReadLine();
ICredentials credentials = new NetworkCredential(strUser,strPassword);
try
ws.Credentials = credentials;
Console.WriteLine(ws.echoString("Hello World"));
catch (Exception err)
Console.WriteLine(err.Message);
finally
Console.ReadLine();

Design Problem : How to design/code a java client which is deployed to all the machines in a cluster and make sure that only one of the java client is active

          hi ,
          I have to design a java client (which is basically a JMS message listener)which
          is deplloyed to all the servers in the cluster. But as these are message listeners,
          i want only one of the instance to be active at a time.
          If the server on which the client is active goes down , I want the second server
          to start listening to messages.
          How do i design this ? Also is there a public api for multicasting that we can
          use ?
          Anybody has an idea on how to go about this..
          Thanks
          nisha


Hi Nisha,
          Failover message listeners? Sounds like you want MDBs, which are deployed on all nodes in a
          cluster. If your JMS destination is a queue, then only one MDB will pick up the message. And just
          like any other ejb service, MDBs failover.
          Gene
          "Nisha" <[email protected]> wrote in message news:[email protected]..
          hi ,
          I have to design a java client (which is basically a JMS message listener)which
          is deplloyed to all the servers in the cluster. But as these are message listeners,
          i want only one of the instance to be active at a time.
          If the server on which the client is active goes down , I want the second server
          to start listening to messages.
          How do i design this ? Also is there a public api for multicasting that we can
          use ?
          Anybody has an idea on how to go about this..
          Thanks
          nisha

Web Service, SSL and Client Authentication

I tried to enable SSL with client authentication over a web service. I am using App Server 10.1.3.4.
The test page requires my certificate (firefox asks me to choose the certificate) the response page of the web service returns this error:
java.security.PrivilegedActionException: javax.xml.soap.SOAPException: Bad response: 405 Method Not Allowed
Has anyone used web services with SSL client authentication?
Any clue why?
Regards

Any comment?
Thank you.

Error in the Socket Communication between Java Client and VC++ Server

In my application, using Java Client to do socket bi-communication with VC++ Server, which is done by somebody else.
The error is after the application properly running one or two days, the VC++ Server cannot receive the messages passed by java Client, but at Java client, everything is the same, although using CheckError() after every print(), there is no exception thrown.
The JVM is jdk1.3.1, platform is Win2k Server.
The outputstream is PrintWriter().
Please help me to settle down this problem. Thanks in advance.

I read some thread in the forum, and found somebody had the similar problem with me. Just want to know how to settle this problem.
In the client/server program. Client is a JAVA program and Server a
VC++ program. The connection works, and the problem appears after some time. The Client sends a lots of requests to Serverm, the server seems receive nothing. But at the same time, the server is able to send messages to Client. The Client also can get the messages and handle them. Don't understand why there this problem and why it appears when it wants.
The client is a Win2k platorm with JDK1.3.1 and the server is also a Win2K platform with VC++ 6.0.
In the Client, using:
inputFromServer = new BufferedReader(new InputStreamReader(socket.getInputStream()));
outputToServer = new PrintWriter(new BufferedWriter(new OutputStreamWriter(socket.getOutputStream())),true);
Hope can get your help.

XI 3.0 and external Java client/web service

Hello,
I'm desperately tryin' to get an external system to work together with XI 3.0.
The setup is quite simple:
The external system is nothing but a simple Java program sending SOAP-based requests to a webservice. It is based on AXIS and is running satisfyingly when connecting directly to an appropriate Tomcat/AXIS-based web service, see the following communication.
-- local request
POST /axis/VAPService.jws HTTP/1.0
Content-Type: text/xml; charset=utf-8
Accept: application/soap+xml, application/dime, multipart/related, text/*
User-Agent: Axis/1.1
Host: 192.168.1.2:8080
Cache-Control: no-cache
Pragma: no-cache
SOAPAction: "http://localhost/SOAPRequest"
Content-Length: 422
<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Body>
<SOAPRequest soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
   <SOAPDataIn xsi:type="xsd:string">890000001</SOAPDataIn>
</SOAPRequest>
</soapenv:Body>
</soapenv:Envelope>
-- local response
HTTP/1.1 200 OK
Set-Cookie: JSESSIONID=DFD7A00A244C18A058FCB52A8321A167; Path=/axis
Content-Type: text/xml;charset=utf-8
Date: Mon, 23 Aug 2004 06:52:47 GMT
Server: Apache-Coyote/1.1
Connection: close
<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Body>
<SOAPRequestResponse soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
   <SOAPRequestReturn xsi:type="xsd:int">1</SOAPRequestReturn>
</SOAPRequestResponse>
</soapenv:Body>
</soapenv:Envelope>
Now I have designed and configured simple business scenarios with XI 3.0 (synchronous as well as asynchronous). The only response I get from XI when the Java client connects ist the following:
-- remote request
POST /sap/xi/engine?type=entry HTTP/1.0
Content-Type: text/xml; charset=utf-8
Accept: application/soap+xml, application/dime, multipart/related, text/*
User-Agent: Axis/1.1
Host: <host>:<port>
Cache-Control: no-cache
Pragma: no-cache
SOAPAction: "http://soap.org/soap"
Content-Length: 424
<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Body>
<SOAPRequest soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
   <SOAPDataIn xsi:type="xsd:string">890000001</SOAPDataIn>
</SOAPRequest>
</soapenv:Body>
</soapenv:Envelope>
-- remote response
HTTP/1.0 500 HTTP standard status code
content-type: text/xml
content-length: 1493
content-id: <[email protected]>
server: SAP Web Application Server (1.0;640)
<SOAP:Envelope xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP:Header>
</SOAP:Header>
<SOAP:Body>
<SOAP:Fault xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/" xmlns:SAP="http://sap.com/xi/XI/Message/30" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:wsu="http://www.docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:wsse="http://www.docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" SOAP:mustUnderstand="1">
   <SOAP:faultcode>Client</SOAP:faultcode>
   <SOAP:faultstring></SOAP:faultstring>
   <SOAP:faultactor>http://sap.com/xi/XI/Message/30</SOAP:faultactor>
   <SOAP:faultdetail>
      <SAP:Error xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/" xmlns:SAP="http://sap.com/xi/XI/Message/30" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:wsu="http://www.docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:wsse="http://www.docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" SOAP:mustUnderstand="1">
         <SAP:Category>XIProtocol</SAP:Category>
         <SAP:Code area="PARSER">UNEXSPECTED_VALUE</SAP:Code>
         <SAP:P1>Main/@versionMajor</SAP:P1>
         <SAP:P2>000</SAP:P2>
         <SAP:P3>003</SAP:P3>
         <SAP:P4></SAP:P4>
         <SAP:AdditionalText></SAP:AdditionalText>
         <SAP:ApplicationFaultMessage namespace=""></SAP:ApplicationFaultMessage>
         <SAP:Stack>XML tag Main/@versionMajor has the incorrect value 000. Value 003 expected
         </SAP:Stack>
      </SAP:Error>
   </SOAP:faultdetail>
</SOAP:Fault>
</SOAP:Body>
</SOAP:Envelope>
I made sure the business service in the integration directory is named SOAPRequest and is using SOAP as the communication channel. As the adapter engine I chose the integration server, since it is the only option, although the SOAP adapter framework is installed (according to the SLD) and deactivated any options like header and attachment.
Upon facing the above response I also tried any kind of derivative with inserting the described tag/attribute/element versionMajor, but to no avail.
My questions are:
What do I have to do additionally to get the whole thing running, i.e. configure my external systems in the SLD, providing proxy settings?
Do I have to create web services within the Web AS (which provide some kind of facade to the XI engine using the proxy generation) and connect to these instead of directly addressing the integration engine (I'm using the URL http://<host>:<port>/sap/xi/engine?type=entry, but I also tried http://<host>:<port>/XISOAPAdapter/MessageServlet?channel=:SOAPRequest:SOAPIn, this led to a 404 not found error)?
What settings do I have to provide to see the messages the client is sending, when looking into the runtime workbench it seems as if there are no messages at all - at least from my client?
Hopefully somebody might help me out or least provide some information to get me going.
Thanks in advance.
Best regards,
T.Hrastnik

Hello Oliver,
all information I gathered so far derives from the online help for XI 3.0, to be found under http://help.sap.com/saphelp_nw04/helpdata/en/14/80243b4a66ae0ce10000000a11402f/frameset.htm. There You'll find - in the last quarter of the navigation bar on the left side - sections describing the adapter engine alonside the SOAP adapter.
Additionally I went through almost all postings in this forum.
This alonside the mandatory trial-and-error approach (I did a lot of it up to date) led me to my current status, i.e. so far I haven't found any kind of (simple) tutorial or demo saying "If You want to establish a web service based connection via SOAP between external applications and XI first do this, then that ...", sadly enough :-(.
Hope that helps, any questions are always welcome, I'll try my best to answer them ;-).
Best regards,
Tomaz

WebServices and Java/Weblogic RPC Client

Hi,
I have a simple usability question :
- Where would I want to use a java client that invokes the (WebLogic) Webservice
using RPC/SOAP - especially the static client model?
- Probably the corollary to that would be - why wouldn't I simply invoke the ejb
using the EJB interface invocation?
In both cases, the information required by the developer to write the code is
same, the coding effort is same (only the Properties object being passed to obtain
the InitialContext is populated with different values) - and everything is hardcoded
i.e. no dynamic behavior advantage.
I ran some quick and dirty benchmarks and the webService client is slower than
the mundane ejb client to the order of magnitude of 1:4, 1:5. (duh .. xml!)
Two advantages that I can think of are :
- Because of HTTP, firewall/port issues may be circumvented when using WebServices.
- The thin client.jar maybe easier to distribute than weblogic.jar.
Shall deeply appreciate any insight to the utility from a business perspective
(read ~ convincing clients).
Thanks,
Ajay

It took me almost 3 seconds to find this so I can see why you would ask. http://java.sun.com/webservices/tutorial.html

Java client for Adep dataservice fill and syncFill

Iam trying to invoke Adep Data services from a java client, but unable to get any help. I would like to invoke fill and syncFill operations from a java client both for load testing and to develop a separate java mobile client application taht wroks with Adep. I tried the following, but does not work from client:
                DataMessage msg = new DataMessage();
                msg.setTimestamp(System.currentTimeMillis());
                msg.setDestination(destinationId);
                msg.setOperation(DataMessage.FILL_OPERATION);
                MessageBroker.getMessageBroker(null).getService("data-service").serviceMessage(msg);
Can you please point me in the right direction.
Thanks
Vijay

Hi Vijay,
At this time, Java, iOS and HTML5/JS clients do not support Data Management Service (DMS). Only Flex based clients support Data Management. That said:
1. From server side, you can invoke Data Management using the DataServiceTransaction (DST) API to invoke fill etc. methods.See the following section of the LCDS guide for an example: http://help.adobe.com/en_US/LiveCycleDataServicesES/3.1/Developing/WS4 ba8596dc6a25eff5473e3781271fa38d0b-7fff.html
2. You could write a remoting destination that exposes methods that internally use DST to invoke fill etc. methods. And you can invoke this remoting destination from the various clients.
Rohit

Diff between Java,Window and HTML Clients

Hi can any body clear me
what is the difference between
1. JAVA Client
2. Windows Client
3. HTML Client.
regards
mmukesh

The Windows client requires SAPGUI for Windows loaded on the dekstop (400+ MB of disk), but it works most efficiently.
The HTML client requires an ITS and is not as efficient, but need no specialized software on the desktop.
The Java client is almost never used except by Mac and Unix users!
Cheers
try searching SDN for SAPGUI variants for more details

JAAS and Java client authentication

Similar Messages

Maybe you are looking for