RE: Different realms

[Imanuel Greenfeld]

Thank you Todd.

 

Appreciated.

 

I understand everything you are saying, but I think you misunderstand me.

 

So I'm re-sending you the existing code.  Any ideas how this needs to change so 
that I can authenticate ?  For example, do I need to encrypt the JSON message 
before calling json_call ?

 

 

struct SOAP_ENV__Header

{

struct ns3__Header *ns3__MyHeader; };

 

struct ns3__Header

{

char *Username;

char *Password;

};

 

soap * mysoap = soap_new1(SOAP_C_UTFSTRING); soap_init(); mysoap.header 
= (SOAP_ENV__Header *)soap_malloc(, sizeof(SOAP_ENV__Header)); 
mysoap.header->ns3__MyHeader = (ns3__Header*)malloc(sizeof(ns3__Header));

 

 

/**  I know that hard coding username and password is contrary to Kerberos 
but I'm just trying to see if I can pass the authentication. **/

 

mysoap.header->ns3__MyHeader->Username = (char*)malloc(10 * sizeof(char));

strcpy(mysoap.header->ns3__MyHeader-> Username,  ""); 
 

 

mysoap.header->ns3__MyHeader-> Password = (char*)malloc(10 * sizeof(char)); 

strcpy(mysoap.header->ns3__MyHeader-> Password,  "");

 

const char *endpointURL = "http://...;;

value request(mysoap), response(mysoap);   

 

... // now populate the request data to send

request[0] = ...;

request[1] = ...;

 

if (json_call(mysoap, endpointURL, request, response)) {

  ... // use response value

}

 

 

Thank you.

 

Imanuel.

 

 

From: Todd Grayson [mailto:tgray...@cloudera.com] 
Sent: 28 January 2018 21:30
To: Imanuel Greenfeld <imanuel.greenfe...@ntlworld.com>
Cc: Robbie Harwood <rharw...@redhat.com>; kerberos@MIT.EDU; Simo Sorce 
<s...@redhat.com>
Subject: Re: Different realms

 

Imanuel,

 

You are describing a custom implementation of some sort, or we are confusing 
terminology of "Service ticket" vs "Kerberos Keytab".

 

  I'm afraid what you are describing is flawed in its premise that a kerberos 
keytab is ever actually "presented" over the wire in the way you are detailing. 
 A service ticket is what is conveyed, and each side uses its respective 
kerberos authentication and Ticket Granting Ticket, Service Ticket and in the 
case of multi-realm, the cross realm trust kerberos principal which is based on 
a shared secret (key, which is a password encrypted by agreed upon encryption 
types).

 

I hope (given your CC of the redhat team member) that you are not describing 
something you are attempting to code within the keycloak implementation or 
something similar to that.  Keycloak plays by the same SPNEGO authentication 
rules as well.

 

http://blog.keycloak.org/2015/04/kerberos-support-in-keycloak.html 

 

This might be an important read to get through so we are all discussing the 
same contexts along with that keycloak discussion.

 

https://msdn.microsoft.com/en-us/library/ms995331.aspx

 

The HTTP 401 response is to direct a client to begin negotiating 
authentication, with kerberos SPNEGO being an example of what can be done 
(Windows NTLM authentication, etc).  The HTTP 401 error would be indicating the 
client failed to properly negotiate authentication on its side and is most 
likely properly set up session context in its response to the server. 

 

If things work with setting up negotiation but then an error occurs (HTTP 403 
error) processing the response,, this can take place for a number of reasons.   
The 403 error can be based on  issues with encryption types in use, or other 
failures at the mechanism layer. 

 

Understand you would never transmit a keytab in that way over the wire.  

 

The service ticket would be espressed as a SPNEGO token for authentication and 
maintained throughout the client interaction.  The cross realm trust in the 
background, and the cross realm principal and its shared key (password) and 
common encryption types allow both sides of the connection to validate the 
token being exchanged. 

 

It would defeat the kerberos security design to present a kerberos keytab over 
the wire. Service ticket would be what gets presented by a client to a kerberos 
authenticated service, and SPNEGO describes that process implemented over HTTP. 
 Cross realm trust is fundamental to things working.  The presentation of a 
keytab that is not related to a KDC realm the actual service is running in is 
not going to work. 

 

Datafusion had a really good wiki page covering this in a visual way, 
unfortunately it looks like that site is down, but the internet wayback 
archives still have it.  This does a good job of breaking down the logic of the 
kerberos authentication model in a visual way...  SPNEGO is HTTP based kerberos 
authentication using the Service Principal Negotiated authentication mechanism 
that builds on top of these concepts.   This gives a visual breakdown of the 
lengths the kerberos protocol, an

RE: Different realms

[Imanuel Greenfeld]

Thank you Robbie.

Appreciated.

The problem is that we're 6 months into the project and we'll have to start
again using libcurl instead of gSoap.

So I'm re-sending you the existing code.  Any ideas how this needs to change
so that I can authenticate ?


struct SOAP_ENV__Header
{
struct ns3__Header *ns3__MyHeader;  
};

struct ns3__Header
{
char *Username;
char *Password;
};

soap * mysoap = soap_new1(SOAP_C_UTFSTRING);  
soap_init();
mysoap.header = (SOAP_ENV__Header *)soap_malloc(,
sizeof(SOAP_ENV__Header));
mysoap.header->ns3__MyHeader = (ns3__Header*)malloc(sizeof(ns3__Header));


/**  I know that hard coding username and password is contrary to
Kerberos but I'm just trying to see if I can pass the authentication.
**/

mysoap.header->ns3__MyHeader->Username = (char*)malloc(10 * sizeof(char));
strcpy(mysoap.header->ns3__MyHeader-> Username,  "");


mysoap.header->ns3__MyHeader-> Password = (char*)malloc(10 * sizeof(char));
strcpy(mysoap.header->ns3__MyHeader-> Password,  "");

const char *endpointURL = "http://...;;
value request(mysoap), response(mysoap);   

... // now populate the request data to send
request[0] = ...;
request[1] = ...;

if (json_call(mysoap, endpointURL, request, response))
{
  ... // use response value
}


Thank you.

Imanuel.

-Original Message-
From: Robbie Harwood [mailto:rharw...@redhat.com] 
Sent: 28 January 2018 19:46
To: Imanuel Greenfeld <imanuel.greenfe...@ntlworld.com>; kerberos@mit.edu
Cc: 'Simo Sorce' <s...@redhat.com>
Subject: RE: Different realms

"Imanuel Greenfeld" <imanuel.greenfe...@ntlworld.com> writes:

> You are right using a script calling curl I managed to send the 
> request and all ok, but it's horrible idea to call curl from C++ and 
> how will I do it ?  system call ?

Curl has a library (libcurl) with bindings you can use:
https://curl.haxx.se/libcurl/

Thanks,
--Robbie


Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Different realms

[Todd Grayson]

Imanuel,

You are describing a custom implementation of some sort, or we are
confusing terminology of "Service ticket" vs "Kerberos Keytab".

  I'm afraid what you are describing is flawed in its premise that a
kerberos keytab is ever actually "presented" over the wire in the way you
are detailing.  A service ticket is what is conveyed, and each side uses
its respective kerberos authentication and Ticket Granting Ticket, Service
Ticket and in the case of multi-realm, the cross realm trust kerberos
principal which is based on a shared secret (key, which is a password
encrypted by agreed upon encryption types).

I hope (given your CC of the redhat team member) that you are not
describing something you are attempting to code within the keycloak
implementation or something similar to that.  Keycloak plays by the same
SPNEGO authentication rules as well.

http://blog.keycloak.org/2015/04/kerberos-support-in-keycloak.html

This might be an important read to get through so we are all discussing the
same contexts along with that keycloak discussion.

https://msdn.microsoft.com/en-us/library/ms995331.aspx

The HTTP 401 response is to direct a client to begin negotiating
authentication, with kerberos SPNEGO being an example of what can be done
(Windows NTLM authentication, etc).  The HTTP 401 error would be indicating
the client failed to properly negotiate authentication on its side and is
most likely properly set up session context in its response to the server.

If things work with setting up negotiation but then an error occurs (HTTP
403 error) processing the response,, this can take place for a number of
reasons.   The 403 error can be based on  issues with encryption types in
use, or other failures at the mechanism layer.

Understand you would never transmit a keytab in that way over the wire.

The service ticket would be espressed as a SPNEGO token for authentication
and maintained throughout the client interaction.  The cross realm trust in
the background, and the cross realm principal and its shared key (password)
and common encryption types allow both sides of the connection to validate
the token being exchanged.

It would defeat the kerberos security design to present a kerberos keytab
over the wire. Service ticket would be what gets presented by a client to a
kerberos authenticated service, and SPNEGO describes that process
implemented over HTTP.  Cross realm trust is fundamental to things
working.  The presentation of a keytab that is not related to a KDC realm
the actual service is running in is not going to work.

Datafusion *had* a really good wiki page covering this in a visual way,
unfortunately it looks like that site is down, but the internet wayback
archives still have it.  This does a good job of breaking down the logic of
the kerberos authentication model in a visual way...  SPNEGO is HTTP based
kerberos authentication using the Service Principal Negotiated
authentication mechanism that builds on top of these concepts.   This gives
a visual breakdown of the lengths the kerberos protocol, and its use over
HTTP, go towards to NEVER transmit a password or keytab representation of a
password) over the network.

https://web.archive.org/web/20170215124230/http://dfusion.com.au/wiki/tiki-index.php?page=Kerberos+Tutorial

On Sun, Jan 28, 2018 at 4:17 AM, Imanuel Greenfeld <
imanuel.greenfe...@ntlworld.com> wrote:

> Thanks Robbie.
>
> Noted.
>
> Ok, let me explain so that all is clear :-
>
> I'm not on Java, I'm on C++.
>
> I am trying to send HTTP request from machine_a (client) to machine_b
> (server) and these 2 realms have no trust between them.
>
> I found a way to get this to work with Java, but I am on C++.  So in Java,
> there is a way to add the keytab to the HTTP request and all works ok.
> Java
> does it like this :-
>
> public void doWithKeytabFile() {
> KerberosRestTemplate restTemplate =
> new KerberosRestTemplate("/tmp/user2.keytab",
> "us...@example.org");
> restTemplate.getForObject("http://neo.example.org:8080/hello;,
> String.class);
> }
>
> As you can see the HTTP request just has one "endpoint" so the keytab needs
> to be part of it.
>
> But in C++ I cannot find a way how to achieve the same - in other words,
> once I have the keytab in the code, and I separately build the HTTP
> request,
> how do I incorporate that keytab to that HTTP request ?
>
> I can only change the client code - the server code is not available to me.
>
> Once again, I'm trying to find C/C++ good example.
>
> Can you help ?
>
> Many thanks
>
> Imanuel.
>
>
> -Original Message-
> From: Robbie Harwood [mailto:rharw...@redhat.com]
> Sent: 28 January 2018 09:31
> To: Imanuel Greenfeld <imanuel.greenfe...@ntlworld.com>; kerberos@mit.edu
> Cc: 'Simo Sorce' <s...@re

RE: Different realms

[Robbie Harwood]

"Imanuel Greenfeld"  writes:

> You are right using a script calling curl I managed to send the
> request and all ok, but it's horrible idea to call curl from C++ and
> how will I do it ?  system call ?

Curl has a library (libcurl) with bindings you can use:
https://curl.haxx.se/libcurl/

Thanks,
--Robbie


signature.asc
Description: PGP signature

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

RE: Different realms

[Imanuel Greenfeld]

Thanks Robbie.

Noted.

Ok, let me explain so that all is clear :-

I'm not on Java, I'm on C++.

I am trying to send HTTP request from machine_a (client) to machine_b
(server) and these 2 realms have no trust between them.

I found a way to get this to work with Java, but I am on C++.  So in Java,
there is a way to add the keytab to the HTTP request and all works ok.  Java
does it like this :-

public void doWithKeytabFile() {
KerberosRestTemplate restTemplate =
new KerberosRestTemplate("/tmp/user2.keytab",
"us...@example.org");
restTemplate.getForObject("http://neo.example.org:8080/hello;,
String.class);
}

As you can see the HTTP request just has one "endpoint" so the keytab needs
to be part of it.

But in C++ I cannot find a way how to achieve the same - in other words,
once I have the keytab in the code, and I separately build the HTTP request,
how do I incorporate that keytab to that HTTP request ?  

I can only change the client code - the server code is not available to me.

Once again, I'm trying to find C/C++ good example.

Can you help ?

Many thanks

Imanuel.


-Original Message-
From: Robbie Harwood [mailto:rharw...@redhat.com] 
Sent: 28 January 2018 09:31
To: Imanuel Greenfeld <imanuel.greenfe...@ntlworld.com>; kerberos@mit.edu
Cc: 'Simo Sorce' <s...@redhat.com>
Subject: RE: Different realms

"Imanuel Greenfeld" <imanuel.greenfe...@ntlworld.com> writes:

> Robbie Harwood <rharw...@redhat.com> writes:
>> "Imanuel Greenfeld" <imanuel.greenfe...@ntlworld.com> writes:
>>
>>> I have 2 domains which there is no trust between them.
>>
>> Do you have two realms (A and B), with two machines (machine_a in A, 
>> and machine_b in B), and two services (service_a on machine_a, and 
>> service_b on machine_b)?
>
> Yes
>
>> I'm not overly familiar with the Java bindings, but this isn't 
>> something one really wants to be doing in Kerberos.
>
> So how can I pass the Kerberos authentication is there is no trust 
> between the realms ?

Without a trust, service_a has no way to *prove* to service_b the identity
of the user who is connecting to service_a.

Now, depending on what you're doing, this may not matter - maybe whatever
service_b is doing doesn't care about that.  If that's the case, then
service_a just needs a credential to authenticate against service_b with.
(This will come from realm B.)

For making Kerberized HTTP requests, the best approach is, as Simo says, to
use something like mod_auth_gssapi on the server.  You're in Java, not
Python, on the client, so you won't be able to use requests-gssapi; I'm not
sure if there is a SPNEGO module for Java.

You can, however, look at how the token is generated by requests-gssapi and
make similar GSSAPI calls from Java - the function is
generate_request_header()
https://github.com/pythongssapi/requests-gssapi/blob/master/requests_gssapi/
gssapi_.py#L139-L150
https://github.com/pythongssapi/requests-gssapi/blob/master/requests_gssapi/
gssapi_.py#L63

>> What is the actual, higher level thing you are trying to accomplish?
>
> As explained, I'm sending HTTP rest JSON request from machine_a to 
> machine_b endpoint but I'm getting Unauthorised 401 error, so I'm 
> trying to incorporate into the HTTP JSON request the keytab which is 
> on machine_a to pass the authentication.

Let me ask a different way.  Why are you doing this at all?

On another note: your email replies are very difficult to read.  At the very
least, please use blank lines to separate your replies from the text you are
replying to, and make your quoting levels work correctly.

Thanks,
--Robbie


Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

RE: Different realms

[Imanuel Greenfeld]

Thank you Robbie.

 

You are right using a script calling curl I managed to send the request and
all ok, but it's horrible idea to call curl from C++ and how will I do it ?
system call ?

 

So, I did this instead so far :-

 

struct SOAP_ENV__Header

{

struct ns3__Header *ns3__MyHeader;  

};

 

struct ns3__Header

{

char *Username;

char *Password;

};

 

soap * mysoap = soap_new1(SOAP_C_UTFSTRING);  

soap_init();

mysoap.header = (SOAP_ENV__Header *)soap_malloc(,
sizeof(SOAP_ENV__Header));

mysoap.header->ns3__MyHeader = (ns3__Header*)malloc(sizeof(ns3__Header));

 

 

/**  I know that hard coding username and password is contrary to
Kerberos but I'm just trying to see if I can pass the authentication.
**/

 

mysoap.header->ns3__MyHeader->Username = (char*)malloc(10 * sizeof(char));

strcpy(mysoap.header->ns3__MyHeader-> Username,  "");


 

mysoap.header->ns3__MyHeader-> Password = (char*)malloc(10 * sizeof(char));

strcpy(mysoap.header->ns3__MyHeader-> Password,  "");

 

const char *endpointURL = "http://...;;

value request(mysoap), response(mysoap);   

 

... // now populate the request data to send

request[0] = ...;

request[1] = ...;

 

if (json_call(mysoap, endpointURL, request, response))

{

  ... // use response value

}

 

I will change the code to process the keytab and pass Username and Password
credentials as you say, but how does this look ?

 

Any ideas how this can be improved to get through the authentication ?

 

Thank you

 

Imanuel.

  

 

-Original Message-
From: Robbie Harwood [mailto:rharw...@redhat.com] 
Sent: 28 January 2018 12:41
To: Imanuel Greenfeld <imanuel.greenfe...@ntlworld.com>; kerberos@mit.edu
Cc: 'Simo Sorce' <s...@redhat.com>
Subject: RE: Different realms

 

"Imanuel Greenfeld" < <mailto:imanuel.greenfe...@ntlworld.com>
imanuel.greenfe...@ntlworld.com> writes:

 

> public void doWithKeytabFile() {

> KerberosRestTemplate restTemplate =

> new KerberosRestTemplate("/tmp/user2.keytab",

> " <mailto:us...@example.org> us...@example.org");

> restTemplate.getForObject(" <http://neo.example.org:8080/hello>
http://neo.example.org:8080/hello;,

> String.class);

> }

> 

> As you can see the HTTP request just has one "endpoint" so the keytab 

> needs to be part of it.

> 

> But in C++ I cannot find a way how to achieve the same - in other 

> words, once I have the keytab in the code, and I separately build the 

> HTTP request, how do I incorporate that keytab to that HTTP request ?

 

The keytab isn't part of the request.  The *credential*, which is derived
from the keytab, is part of the request.

 

> I can only change the client code - the server code is not available to
me.

> 

> Once again, I'm trying to find C/C++ good example.

 

You'll most likely need to write it yourself, which is why I linked you the
requests-gssapi version.  I'm not sure anyone's done the client side of this
from C, other than curl [1].  I don't find that easier to read than the
python, but I'm of course biased.

 

Thanks,

--Robbie

 

1:  <https://github.com/curl/curl> https://github.com/curl/curl


Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

RE: Different realms

[Robbie Harwood]

"Imanuel Greenfeld"  writes:

> public void doWithKeytabFile() {
> KerberosRestTemplate restTemplate =
> new KerberosRestTemplate("/tmp/user2.keytab",
> "us...@example.org");
> restTemplate.getForObject("http://neo.example.org:8080/hello;,
> String.class);
> }
>
> As you can see the HTTP request just has one "endpoint" so the keytab needs
> to be part of it.
>
> But in C++ I cannot find a way how to achieve the same - in other words,
> once I have the keytab in the code, and I separately build the HTTP request,
> how do I incorporate that keytab to that HTTP request ?  

The keytab isn't part of the request.  The *credential*, which is
derived from the keytab, is part of the request.

> I can only change the client code - the server code is not available to me.
>
> Once again, I'm trying to find C/C++ good example.

You'll most likely need to write it yourself, which is why I linked you
the requests-gssapi version.  I'm not sure anyone's done the client side
of this from C, other than curl [1].  I don't find that easier to read
than the python, but I'm of course biased.

Thanks,
--Robbie

1: https://github.com/curl/curl


signature.asc
Description: PGP signature

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

RE: Different realms

[Robbie Harwood]

"Imanuel Greenfeld"  writes:

> Robbie Harwood  writes:
>> "Imanuel Greenfeld"  writes:
>>
>>> I have 2 domains which there is no trust between them.
>>
>> Do you have two realms (A and B), with two machines (machine_a in A,
>> and machine_b in B), and two services (service_a on machine_a, and
>> service_b on machine_b)?
>
> Yes
>
>> I'm not overly familiar with the Java bindings, but this isn't
>> something one really wants to be doing in Kerberos.
>
> So how can I pass the Kerberos authentication is there is no trust
> between the realms ?

Without a trust, service_a has no way to *prove* to service_b the
identity of the user who is connecting to service_a.

Now, depending on what you're doing, this may not matter - maybe
whatever service_b is doing doesn't care about that.  If that's the
case, then service_a just needs a credential to authenticate against
service_b with.  (This will come from realm B.)

For making Kerberized HTTP requests, the best approach is, as Simo says,
to use something like mod_auth_gssapi on the server.  You're in Java,
not Python, on the client, so you won't be able to use requests-gssapi;
I'm not sure if there is a SPNEGO module for Java.

You can, however, look at how the token is generated by requests-gssapi
and make similar GSSAPI calls from Java - the function is
generate_request_header()
https://github.com/pythongssapi/requests-gssapi/blob/master/requests_gssapi/gssapi_.py#L139-L150
https://github.com/pythongssapi/requests-gssapi/blob/master/requests_gssapi/gssapi_.py#L63

>> What is the actual, higher level thing you are trying to accomplish?
>
> As explained, I'm sending HTTP rest JSON request from machine_a to
> machine_b endpoint but I'm getting Unauthorised 401 error, so I'm
> trying to incorporate into the HTTP JSON request the keytab which is
> on machine_a to pass the authentication.

Let me ask a different way.  Why are you doing this at all?

On another note: your email replies are very difficult to read.  At the
very least, please use blank lines to separate your replies from the
text you are replying to, and make your quoting levels work correctly.

Thanks,
--Robbie


signature.asc
Description: PGP signature

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

RE: Different realms

[Imanuel Greenfeld]

Hello Robbie

 

Thanks for the details.

 

Comments below inline.

 

Can you please help ?

 

Thank you

 

Imanuel.

 

 

-Original Message-
From: Robbie Harwood [mailto:rharw...@redhat.com] 
Sent: 26 January 2018 12:55
To: Imanuel Greenfeld <imanuel.greenfe...@ntlworld.com>; kerberos@mit.edu
Cc: 'Simo Sorce' <s...@redhat.com>
Subject: Re: Different realms

 

"Imanuel Greenfeld" < <mailto:imanuel.greenfe...@ntlworld.com>
imanuel.greenfe...@ntlworld.com> writes:

 

> I have 2 domains which there is no trust between them.

> 

> I'm running a process on Domain 1.  This needs to submit HTTP rest 

> request to Domain 2 which the KDC is also on the same domain (i.e. 

> domain 2).

 

What does "domain" mean here?  domain is Realm Do you have two realms (A and
B), with two machines (machine_a in A, and machine_b in B), and two services
(service_a on machine_a, and service_b on machine_b)? Yes

 

> I have keytab (for the service account on Domain 2) and kerb5.conf 

> with the details of the two realms.

 

So if I understand correctly: on machine_b, you have a keytab for service_b.
No : on machine_a I have the keytab for service_b And krb5.conf knows the
KDCs and such for both A and B. Yes : krb5.conf is on machine_a but has
entries for both realms.

 

> I found a way to incorporate the keytab into the HTTP request in Java 

> but not in C/C++.

 

I lose you here.  It sounds like you're sending the keytab as part of the
HTTP request?  Yes, that's because I'm sending HTTP JSON request from
machine_a to machine_b endpoint but I'm getting Unauthorised 401 error
because I'm not passing the Kerberos authentication - in Java you can use
RestTemplate which lets you incorporate into the HTTP JSON request the
keytab.   I'm not overly familiar with the Java bindings, but this isn't
something one really wants to be doing in Kerberos.  So how can I pass the
Kerberos authentication is there is no trust between the realms ? 

 

> I know there are functions such as krb5_get_init_creds_keytab but I do 

> not know how to achieve the same in C/C++ (as I did in Java).  So when 

> I have the keytab, how do I incorporate this to the HTTP header ?

 

You shouldn't be passing credentials around for security reasons, and you
shouldn't be putting thins of variable length in headers.  Understood.

 

What is the actual, higher level thing you are trying to accomplish?  As
explained, I'm sending HTTP rest JSON request from machine_a to machine_b
endpoint but I'm getting Unauthorised 401 error, so I'm trying to
incorporate into the HTTP JSON request the keytab which is on machine_a to
pass the authentication.

 

Thanks,

--Robbie


Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Different realms

[Robbie Harwood]

"Imanuel Greenfeld"  writes:

> I have 2 domains which there is no trust between them.
>
> I'm running a process on Domain 1.  This needs to submit HTTP rest
> request to Domain 2 which the KDC is also on the same domain
> (i.e. domain 2).

What does "domain" mean here?  Do you have two realms (A and B), with
two machines (machine_a in A, and machine_b in B), and two services
(service_a on machine_a, and service_b on machine_b)?

> I have keytab (for the service account on Domain 2) and kerb5.conf
> with the details of the two realms.

So if I understand correctly: on machine_b, you have a keytab for
service_b.  And krb5.conf knows the KDCs and such for both A and B.

> I found a way to incorporate the keytab into the HTTP request in Java but
> not in C/C++.

I lose you here.  It sounds like you're sending the keytab as part of
the HTTP request?  I'm not overly familiar with the Java bindings, but
this isn't something one really wants to be doing in Kerberos.

> I know there are functions such as krb5_get_init_creds_keytab but I do
> not know how to achieve the same in C/C++ (as I did in Java).  So when
> I have the keytab, how do I incorporate this to the HTTP header ?

You shouldn't be passing credentials around for security reasons, and
you shouldn't be putting thins of variable length in headers.

What is the actual, higher level thing you are trying to accomplish?

Thanks,
--Robbie


signature.asc
Description: PGP signature

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos