Hi All, The name-formats used in GSS-API are somewhat different than the name-formats used in SSPI. So the C# client could not identify the SPN, as the SPN name of the Java server is not windows compatible. After providing the SPN name without realm when creating the client credentials in C# client side the above problem solved.
Thanks Fara and Shazni for the suggestions and all the help. :) Hasanthi Dissanayake Software Engineer | WSO2 E: hasan...@wso2.com M :0718407133| http://wso2.com <http://wso2.com/> On Tue, Jun 21, 2016 at 4:36 PM, Farasath Ahamed <farasa...@wso2.com> wrote: > Hi Hasanthi, > > > On Tue, Jun 21, 2016 at 3:01 PM, Hasanthi Purnima Dissanayake < > hasan...@wso2.com> wrote: > >> Hi Fara/Shazni, >> >> Thanks for the feedback. Here I'm using a sample standalone Java server >> and C# client which communicates through a socket. And I'm using the fully >> qualified name as you suggested. >> >> As this error comes when validating the server token the the issue should >> be with the SPN of java server. Following is the code snippet which I'm >> using generate the server token. >> >> GSSName serviceName = >> manager.createName("wso2@IS.LOCAL", GSSName.NT_USER_NAME); >> > > You seem to be using the service account here. Can you try using the > Service Principal name under which you registered the java sever (that will > be something like HTTP/server.is.local@IS.LOCAL) instead. As Shazni has > pointed out use the SPN name along with realm at all places. I faced a > similar situation during implementing IWA using Kerberos, and giving the > SPN name along with the domain did the trick for me. > > > >> GSSCredential serviceCredentials = >> manager.createCredential(serviceName, >> GSSCredential.INDEFINITE_LIFETIME, spnegoOid, >> GSSCredential.ACCEPT_ONLY); >> GSSContext context = >> manager.createContext(serviceCredentials); >> serverToken = context.acceptSecContext(serviceTicket, >> 0, serviceTicket.length); >> >> Here IS.LOCAL is the realm name and wso2 is the account name. When >> executing this I got a value for 'serverToken' and the exception occurs >> when the client uses this 'serverToken' to validate. >> >> Thanks, >> >> Hasanthi Dissanayake >> >> Software Engineer | WSO2 >> >> E: hasan...@wso2.com >> M :0718407133| http://wso2.com <http://wso2.com/> >> >> On Tue, Jun 21, 2016 at 2:32 PM, Shazni Nazir <sha...@wso2.com> wrote: >> >>> HI Hasanthi, >>> >>> I've one question. What's this Java Server? Is it a standalone server >>> you have custom written or is it a WSO2 server? >>> >>> When it comes to Kerberos related work for SOAP, we faced a couple of >>> issues with related to service principal (SPN) name. In that discrepancies >>> were noticed when using service principal name without a realm. For >>> example, if the service principal name is, esb/localhost and the realm is >>> WSO2.ORG, you have to specify the SPN as a fully qualified name; like >>> esb/localh...@wso2.org. I'm not sure whether your issue is related to >>> this. Maybe you can check if that's the case. >>> >>> Shazni Nazeer >>> Mob : +94 777737331 >>> LinkedIn : http://lk.linkedin.com/in/shazninazeer >>> Blog : http://shazninazeer.blogspot.com >>> >>> On Tue, Jun 21, 2016 at 2:20 PM, Farasath Ahamed <farasa...@wso2.com> >>> wrote: >>> >>>> Hi Hasanthi, >>>> >>>> Assuming that you are using an AD as the Kerberos Server, Have you >>>> registered a Service Principal for both the C# client and Java Server in >>>> the AD? >>>> >>>> You can do this using the setspn.exe. Also, when you registering the >>>> SPN register all possible value that principal can take. >>>> For eg: Let's say the hostname of your java server is *server.is.local*, >>>> you can do >>>> >>>> setspn -A HTTP/server.is.local <service_account> >>>> setspn -A HTTP/server <service_account> >>>> >>>> to add your java server as a service principal in the Kerberos Server. >>>> You can do the same for the C# client as well. Can you check whether you >>>> have already registered the Service Principals by listing them out using >>>> commands specified in [1] >>>> >>>> [1] >>>> https://blogs.msdn.microsoft.com/psssql/2009/02/13/searching-for-duplicate-spns-got-a-little-easier/ >>>> >>>> Thanks, >>>> >>>> Farasath Ahamed >>>> Software Engineer, >>>> WSO2 Inc.; http://wso2.com >>>> lean.enterprise.middleware >>>> >>>> >>>> Email: farasa...@wso2.com >>>> Mobile: +94777603866 >>>> Blog: blog.farazath.com >>>> Twitter: @farazath619 <https://twitter.com/farazath619> >>>> >>>> On Tue, Jun 21, 2016 at 2:03 PM, Hasanthi Purnima Dissanayake < >>>> hasan...@wso2.com> wrote: >>>> >>>>> Hi I'm implementing Kerberos communication between java (GSSAPI) to >>>>> C#(SSPI). >>>>> >>>>> The KDC is an Active Directory. When it comes to Java client vs Java >>>>> server and C# client vs C# Server, for both the scenarios this works fine. >>>>> >>>>> When using Java client - server the process happens as below and it >>>>> works fine: >>>>> * Client uses JAAS and creates TGT in client side >>>>> * Server uses JAAS and creates TGT in server side >>>>> * Client uses service principle name of the server to create the >>>>> context and using that context it invokes initSecContext and creates SGT >>>>> and pass it to the server >>>>> * Server uses acceptSecContext() to validate the SGT >>>>> >>>>> When using C# client -server the process happens as below and it >>>>> works fine too >>>>> * Client creates credentials and invokes init() to create client TGT >>>>> * Client passes this TGT to the server and server passes this TGT to >>>>> accept(), to validate the TGT , then generates server TGT and passes it to >>>>> client >>>>> * Client gets the TGT from server and passes it to int() to create the >>>>> SGT >>>>> * Client passes this SGT to server and server uses accept() to >>>>> validate the SGT >>>>> >>>>> When using C# client - Java server te process happens as below. [1][2] >>>>> * Client creates credentials and invokes init() to create TGT >>>>> * Client passes this TGT to the server and server use this TGT and >>>>> passes it to acceptSecContext() to validate the TGT and to generate server >>>>> TGT and passes it to client >>>>> * Client gets the TGT from server and passes it to int() to create the >>>>> SGT and pass the SGT to server. >>>>> * Server uses acceptSecContext() to validate the SGT >>>>> >>>>> When I'm implementing the third use case it fails to validate the TGT >>>>> of Java server from the C# client side with the following exception. >>>>> >>>>> "Failed to invoke InitializeSecurityContext for a client. The >>>>> specified principle is not known in the authentication system." >>>>> >>>>> [1] >>>>> https://msdn.microsoft.com/en-us/library/windows/desktop/aa380496(v=vs.85).aspx >>>>> [2] https://msdn.microsoft.com/en-us/library/ms995352.aspx >>>>> >>>>> Any suggestion is highly appreciated to recover this issue. >>>>> >>>>> Thanks, >>>>> >>>>> >>>>> >>>>> Hasanthi Dissanayake >>>>> >>>>> Software Engineer | WSO2 >>>>> >>>>> E: hasan...@wso2.com >>>>> M :0718407133| http://wso2.com <http://wso2.com/> >>>>> >>>> >>>> >>> >> > Thanks, > Farasath > >
_______________________________________________ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
