Automate

We are new to Winshuttle and have Foundation installed with Workflow/Composer.  Currently, we are working on developing our first production workflow application.  The application will be a workflow for creating purchase requisitions.  Being as this will be a widely used application by many users, we want to make the application pretty flexible and easy to use and maintain.  Our development hit a huge snag, though.  We use Kerberos SNC SSO (Single Sign-On) for connecting to SAP.  Therefore, we were hoping to use Kerberos SSO for the Workflow application.  We haven't been able to get it to work, however, and are hoping perhaps someone else has. 

We have been told all long that this is possible, but after our most recent encounter with support we were told it's not possible.  We have been given three potential workarounds for this: 1) store and maintain everyone's Windows credentials in Foundation, 2) run the Workflow SAP web services under a dedicated service account, and 3) add credential inputs into each and every workflow.

The first option is not feasible and goes against our security policies, as it requires hundreds of users storing and updating their credentials in SharePoint.  

The second option won't work either because it requires a dedicated service account to have full SAP permissions to account for all users who might potentially use the application.  We lose the major selling point of Winshuttle's ability to play nicely with SAP security.

The third option negates the whole point of SSO.     

We were hoping someone else has run into this issue and successfully implemented SSO.  Even if it means we move to another form/implementation of SSO, we would consider it.  Kerberos with multiple hops is a very common scenario, so we're trying to understand where the problem is that does not allow for the Kerberos authentication to pass all the way through to SAP.  I'm not sure about the exact architecture of the Workflow application, but my guess is that it works something like this: 

1) User connects to Workflow which resides on the Foundation/SharePoint server.
2) Workflow server makes an HTTP call out to integration (or perhaps the call is an AJAX call from the client)
3) Integration Server makes call to SAP

Now the fuzzy part is on the integration server - my guess is that the call from Workflow SharePoint application to the integration server is made via HTTP to the WinshuttleServer website's web service.  From there, I'm guessing there's a means of passing the data to the Worker Windows service.  I know RabbitMQ is used, so I'm guessing perhaps this is the means of passing information between the web service and the windows service using RPC (request/reply), but perhaps I'm wrong?  From there, I'm assuming the windows service reads the message, makes the request to SAP, and returns the data back to the web service on the integration server, which then returns the data back to the Workflow server (or client if it's an AJAX call).  If this is the case, then my assumption is the problem likely lies in the RabbitMQ aspect.  Perhaps they haven't figured out how to pass the ticket through the queue.  From what I know of Kerberos, as long as you can identify the services and dedicate authorized service accounts for them, then you should be able to delegate the hops.  I know there is a Kerberos authentication module for RabbitMQ, but it might not be for hopping the identity from publisher to subscriber, but I would assume you could include the ticket in the message itself.  Perhaps this isn't where the issue lies.  I would like to understand, because it seems like a solvable problem, and right now we cannot move forward with Winshuttle without it being solved.

------------------------------
Zachary Daily
Application & Systems Development Engineer
BWX Technologies Inc.
------------------------------

Hi Zachary,

Your analysis of the call looks right, here's my understanding (SAPIS = WinshuttleServer):

1. User on the workflow initiates a web service call.
2. The workflow engine checks Foundation User Governance through an HTTP call for a user license and the connection string properties for the SAP server as defined on that User Governance site.
3. The workflow engine then calls the particular published web service, which is stored on the SAPIS manager site.
4. The SAPIS manager site puts the job into the RabbitMQ queue.
5. The SAPIS worker services pull from the queue and pass the XML package through RFC to SAP.
6. The SAPIS worker services send the completed package back to the SAPIS manager site.
7. The SAPIS manager site sends the response XML back to the form via the workflow engine.

We use Kerberos as well with SAP SSO. I'm not sure if our SAP SSO is the same as SNC SSO for SAP. We are on v12 which is the first version that natively supports our type of SAP SSO.

As far as I know, there was no additional setup for RabbitMQ. We did have to create SPN's for every Winshuttle account with delegation to every other communicating server's service accounts and we do have to exchange SNC certificates between the Winshuttle SAPIS server and each SAP system.

In your SAPIS worker logs, are you seeing any indication that the web service is getting that far?

------------------------------
Joshua Whitener | Winshuttle Evangelist
Exxon Mobil Corporation | 8326258441
------------------------------

Original Message:
Sent: 04-02-2019 10:35
From: Zachary Daily
Subject: Workflow Kerberos Authentication

We are new to Winshuttle and have Foundation installed with Workflow/Composer.  Currently, we are working on developing our first production workflow application.  The application will be a workflow for creating purchase requisitions.  Being as this will be a widely used application by many users, we want to make the application pretty flexible and easy to use and maintain.  Our development hit a huge snag, though.  We use Kerberos SNC SSO (Single Sign-On) for connecting to SAP.  Therefore, we were hoping to use Kerberos SSO for the Workflow application.  We haven't been able to get it to work, however, and are hoping perhaps someone else has.

We have been told all long that this is possible, but after our most recent encounter with support we were told it's not possible.  We have been given three potential workarounds for this: 1) store and maintain everyone's Windows credentials in Foundation, 2) run the Workflow SAP web services under a dedicated service account, and 3) add credential inputs into each and every workflow.

The first option is not feasible and goes against our security policies, as it requires hundreds of users storing and updating their credentials in SharePoint.

The second option won't work either because it requires a dedicated service account to have full SAP permissions to account for all users who might potentially use the application.  We lose the major selling point of Winshuttle's ability to play nicely with SAP security.

The third option negates the whole point of SSO.

We were hoping someone else has run into this issue and successfully implemented SSO.  Even if it means we move to another form/implementation of SSO, we would consider it.  Kerberos with multiple hops is a very common scenario, so we're trying to understand where the problem is that does not allow for the Kerberos authentication to pass all the way through to SAP.  I'm not sure about the exact architecture of the Workflow application, but my guess is that it works something like this:

1) User connects to Workflow which resides on the Foundation/SharePoint server.
2) Workflow server makes an HTTP call out to integration (or perhaps the call is an AJAX call from the client)
3) Integration Server makes call to SAP

Now the fuzzy part is on the integration server - my guess is that the call from Workflow SharePoint application to the integration server is made via HTTP to the WinshuttleServer website's web service.  From there, I'm guessing there's a means of passing the data to the Worker Windows service.  I know RabbitMQ is used, so I'm guessing perhaps this is the means of passing information between the web service and the windows service using RPC (request/reply), but perhaps I'm wrong?  From there, I'm assuming the windows service reads the message, makes the request to SAP, and returns the data back to the web service on the integration server, which then returns the data back to the Workflow server (or client if it's an AJAX call).  If this is the case, then my assumption is the problem likely lies in the RabbitMQ aspect.  Perhaps they haven't figured out how to pass the ticket through the queue.  From what I know of Kerberos, as long as you can identify the services and dedicate authorized service accounts for them, then you should be able to delegate the hops.  I know there is a Kerberos authentication module for RabbitMQ, but it might not be for hopping the identity from publisher to subscriber, but I would assume you could include the ticket in the message itself.  Perhaps this isn't where the issue lies.  I would like to understand, because it seems like a solvable problem, and right now we cannot move forward with Winshuttle without it being solved.

------------------------------
Zachary Daily
Application & Systems Development Engineer
BWX Technologies Inc.
------------------------------

When we execute a service in a workflow, we get the following error:

An error occurred while calling service.
Exception has been thrown by the target of an invocation.
Error occurred while consuming published service.
Error message received from Worker: Error from processor: The current Windows credentials are either not available or not adequate for SSO login.
ErrorCode: 2046

I'm guessing that the identity is lost along the hops somehow and it's trying to access SAP anonymously.  If we store our windows credentials in Foundation, then it will lookup the credentials based on our Kerberos identity from the Workflow site and use those for the call to SAP.

Based on what you're saying, it sounds like your Workflow users don't need to store their windows credentials and Kerberos is setup and successfully carries the identity all the way through to the SAP call without having to re-authenticate along the way.  Correct?  We're using Product Version : 11.2.5 - Enterprise (11.20.05170.7201).  We heard about improvements with Kerberos on v12 but weren't sure what exactly they are.  By "natively supports", do you mean they provide the SAP Kerberos dlls for you? (i.e. gsskrb5.dll and gx64krb5.dll)  I'd be interested to know how the websites and Kerberos are configured to see if I could match them in our QA environment.  Perhaps it will only work in v12.

------------------------------
Zachary Daily
Application & Systems Development Engineer
BWX Technologies Inc.
------------------------------

Original Message:
Sent: 04-03-2019 08:31
From: Joshua Whitener
Subject: Workflow Kerberos Authentication

Hi Zachary,

Your analysis of the call looks right, here's my understanding (SAPIS = WinshuttleServer):

1. User on the workflow initiates a web service call.
2. The workflow engine checks Foundation User Governance through an HTTP call for a user license and the connection string properties for the SAP server as defined on that User Governance site.
3. The workflow engine then calls the particular published web service, which is stored on the SAPIS manager site.
4. The SAPIS manager site puts the job into the RabbitMQ queue.
5. The SAPIS worker services pull from the queue and pass the XML package through RFC to SAP.
6. The SAPIS worker services send the completed package back to the SAPIS manager site.
7. The SAPIS manager site sends the response XML back to the form via the workflow engine.

We use Kerberos as well with SAP SSO. I'm not sure if our SAP SSO is the same as SNC SSO for SAP. We are on v12 which is the first version that natively supports our type of SAP SSO.

As far as I know, there was no additional setup for RabbitMQ. We did have to create SPN's for every Winshuttle account with delegation to every other communicating server's service accounts and we do have to exchange SNC certificates between the Winshuttle SAPIS server and each SAP system.

In your SAPIS worker logs, are you seeing any indication that the web service is getting that far?

------------------------------
Joshua Whitener | Winshuttle Evangelist
Exxon Mobil Corporation | 8326258441

Original Message:
Sent: 04-02-2019 10:35
From: Zachary Daily
Subject: Workflow Kerberos Authentication

We are new to Winshuttle and have Foundation installed with Workflow/Composer.  Currently, we are working on developing our first production workflow application.  The application will be a workflow for creating purchase requisitions.  Being as this will be a widely used application by many users, we want to make the application pretty flexible and easy to use and maintain.  Our development hit a huge snag, though.  We use Kerberos SNC SSO (Single Sign-On) for connecting to SAP.  Therefore, we were hoping to use Kerberos SSO for the Workflow application.  We haven't been able to get it to work, however, and are hoping perhaps someone else has.

We have been told all long that this is possible, but after our most recent encounter with support we were told it's not possible.  We have been given three potential workarounds for this: 1) store and maintain everyone's Windows credentials in Foundation, 2) run the Workflow SAP web services under a dedicated service account, and 3) add credential inputs into each and every workflow.

The first option is not feasible and goes against our security policies, as it requires hundreds of users storing and updating their credentials in SharePoint.

The second option won't work either because it requires a dedicated service account to have full SAP permissions to account for all users who might potentially use the application.  We lose the major selling point of Winshuttle's ability to play nicely with SAP security.

The third option negates the whole point of SSO.

We were hoping someone else has run into this issue and successfully implemented SSO.  Even if it means we move to another form/implementation of SSO, we would consider it.  Kerberos with multiple hops is a very common scenario, so we're trying to understand where the problem is that does not allow for the Kerberos authentication to pass all the way through to SAP.  I'm not sure about the exact architecture of the Workflow application, but my guess is that it works something like this:

1) User connects to Workflow which resides on the Foundation/SharePoint server.
2) Workflow server makes an HTTP call out to integration (or perhaps the call is an AJAX call from the client)
3) Integration Server makes call to SAP

Now the fuzzy part is on the integration server - my guess is that the call from Workflow SharePoint application to the integration server is made via HTTP to the WinshuttleServer website's web service.  From there, I'm guessing there's a means of passing the data to the Worker Windows service.  I know RabbitMQ is used, so I'm guessing perhaps this is the means of passing information between the web service and the windows service using RPC (request/reply), but perhaps I'm wrong?  From there, I'm assuming the windows service reads the message, makes the request to SAP, and returns the data back to the web service on the integration server, which then returns the data back to the Workflow server (or client if it's an AJAX call).  If this is the case, then my assumption is the problem likely lies in the RabbitMQ aspect.  Perhaps they haven't figured out how to pass the ticket through the queue.  From what I know of Kerberos, as long as you can identify the services and dedicate authorized service accounts for them, then you should be able to delegate the hops.  I know there is a Kerberos authentication module for RabbitMQ, but it might not be for hopping the identity from publisher to subscriber, but I would assume you could include the ticket in the message itself.  Perhaps this isn't where the issue lies.  I would like to understand, because it seems like a solvable problem, and right now we cannot move forward with Winshuttle without it being solved.

------------------------------
Zachary Daily
Application & Systems Development Engineer
BWX Technologies Inc.
------------------------------

So at least it's making it past RabbitMQ to Worker.

Correct, we don't save Windows Credentials. Our SAP SSO settings matches the active directory username of the current user to the SAP username. By natively supports, I mean there is no additional configurations necessary beyond the manual placing the SNC dll files and configuring SAPIS to use them.

SharePoint websites use the standard SharePoint authentication and providers. (Anonymous, ASP.NET, Forms, Windows {negotiate, NTLM}.

SAPIS's Manager site uses Anon and Windows {negotiate, NTLM}

Based on my experience with Winshuttle infrastructure, I would strongly recommend a single service account for Winshuttle applications and services. I can't list out the 12 pages of constrained delegations, but basically every host has to have constrained delegation to every Winshuttle site and SharePoint web application and every service account has to have the same. With additional SPNs for the Winshuttle service account for the current host plus all Winshuttle sites on that host in HTTP/

I tried attaching a picture of the SAP settings in Foundation, but not sure if will come through.



------------------------------
Joshua Whitener | Technical Advisor
Exxon Mobil Corporation | 8326258441
------------------------------

Original Message:
Sent: 04-03-2019 08:31
From: Joshua Whitener
Subject: Workflow Kerberos Authentication

Hi Zachary,

Your analysis of the call looks right, here's my understanding (SAPIS = WinshuttleServer):

1. User on the workflow initiates a web service call.
2. The workflow engine checks Foundation User Governance through an HTTP call for a user license and the connection string properties for the SAP server as defined on that User Governance site.
3. The workflow engine then calls the particular published web service, which is stored on the SAPIS manager site.
4. The SAPIS manager site puts the job into the RabbitMQ queue.
5. The SAPIS worker services pull from the queue and pass the XML package through RFC to SAP.
6. The SAPIS worker services send the completed package back to the SAPIS manager site.
7. The SAPIS manager site sends the response XML back to the form via the workflow engine.

We use Kerberos as well with SAP SSO. I'm not sure if our SAP SSO is the same as SNC SSO for SAP. We are on v12 which is the first version that natively supports our type of SAP SSO.

As far as I know, there was no additional setup for RabbitMQ. We did have to create SPN's for every Winshuttle account with delegation to every other communicating server's service accounts and we do have to exchange SNC certificates between the Winshuttle SAPIS server and each SAP system.

In your SAPIS worker logs, are you seeing any indication that the web service is getting that far?

------------------------------
Joshua Whitener | Winshuttle Evangelist
Exxon Mobil Corporation | 8326258441

Original Message:
Sent: 04-02-2019 10:35
From: Zachary Daily
Subject: Workflow Kerberos Authentication

We are new to Winshuttle and have Foundation installed with Workflow/Composer.  Currently, we are working on developing our first production workflow application.  The application will be a workflow for creating purchase requisitions.  Being as this will be a widely used application by many users, we want to make the application pretty flexible and easy to use and maintain.  Our development hit a huge snag, though.  We use Kerberos SNC SSO (Single Sign-On) for connecting to SAP.  Therefore, we were hoping to use Kerberos SSO for the Workflow application.  We haven't been able to get it to work, however, and are hoping perhaps someone else has.

We have been told all long that this is possible, but after our most recent encounter with support we were told it's not possible.  We have been given three potential workarounds for this: 1) store and maintain everyone's Windows credentials in Foundation, 2) run the Workflow SAP web services under a dedicated service account, and 3) add credential inputs into each and every workflow.

The first option is not feasible and goes against our security policies, as it requires hundreds of users storing and updating their credentials in SharePoint.

The second option won't work either because it requires a dedicated service account to have full SAP permissions to account for all users who might potentially use the application.  We lose the major selling point of Winshuttle's ability to play nicely with SAP security.

The third option negates the whole point of SSO.

We were hoping someone else has run into this issue and successfully implemented SSO.  Even if it means we move to another form/implementation of SSO, we would consider it.  Kerberos with multiple hops is a very common scenario, so we're trying to understand where the problem is that does not allow for the Kerberos authentication to pass all the way through to SAP.  I'm not sure about the exact architecture of the Workflow application, but my guess is that it works something like this:

1) User connects to Workflow which resides on the Foundation/SharePoint server.
2) Workflow server makes an HTTP call out to integration (or perhaps the call is an AJAX call from the client)
3) Integration Server makes call to SAP

Now the fuzzy part is on the integration server - my guess is that the call from Workflow SharePoint application to the integration server is made via HTTP to the WinshuttleServer website's web service.  From there, I'm guessing there's a means of passing the data to the Worker Windows service.  I know RabbitMQ is used, so I'm guessing perhaps this is the means of passing information between the web service and the windows service using RPC (request/reply), but perhaps I'm wrong?  From there, I'm assuming the windows service reads the message, makes the request to SAP, and returns the data back to the web service on the integration server, which then returns the data back to the Workflow server (or client if it's an AJAX call).  If this is the case, then my assumption is the problem likely lies in the RabbitMQ aspect.  Perhaps they haven't figured out how to pass the ticket through the queue.  From what I know of Kerberos, as long as you can identify the services and dedicate authorized service accounts for them, then you should be able to delegate the hops.  I know there is a Kerberos authentication module for RabbitMQ, but it might not be for hopping the identity from publisher to subscriber, but I would assume you could include the ticket in the message itself.  Perhaps this isn't where the issue lies.  I would like to understand, because it seems like a solvable problem, and right now we cannot move forward with Winshuttle without it being solved.

------------------------------
Zachary Daily
Application & Systems Development Engineer
BWX Technologies Inc.
------------------------------

We do have several different accounts throughout the two servers.  Let me see if I can map this out here.  Below are a list of servers, their users, and their app pools or services (Disclaimer - I'm not a SharePoint admin so forgive me for not knowing this aspect of it very well):

SharePoint Server:

• spIntFarm
  • 26b1aaa4dd27448ea63d658cc8479b70 (1 app)
  • 529f0469102d46758a5a1c3f26049b61 (1 app)
  • SecurityTokenServiceApplicationPool (3 apps)
  • SharePoint Central Administration v4 (1 app)
• spIntServices
  • 7375c4d2aef04593ab27eaa8fb854d54 (11 apps)
• spIntSearch
  • 8483f09b7a704e8a9773d57efc4e9eb2 (2 apps)
• spIntAppPool
  • SharePoint - Winshuttle QA (1 app)
• wsWorkflow
  • Winshuttle Workflow Central Administration (1 app)

SAPIS:

• wsAppPool
  • lmsdataapi (1 app)
  • lmsreports (1 app)
  • lmsservices (2 apps)
  • lmssite (2 apps)
  • WinshuttleServer (2 apps)
  • WSComposerAppPool (1 app)
  • WinshuttleWorker (Windows Service)
  • Winshuttle LMS Background Service (Windows Service)
  • WinshuttleWorkerLaunchGui (Windows Service)
  • Loupe Service (Windows Service)

These are the sites/applications (and their respective service accounts) and authentication
SharePoint Server:

• SharePoint (spIntAppPool)
  • Anon
  • Impersonation
  • Forms
  • Windows (Negotiate, NTLM) (Extended Protection - Off, Disabled Kernel-mode authentication)
• SharePoint Admin (spIntFarm)
  • Impersonation
  • Windows (NTLM) (Extended Protection - Off, Disabled Kernel-mode authentication)
• Winshuttle Workflow Central Administration (wsWorkflow)
  • Impersonation
  • Windows (Negotiate, NTLM) (Extended Protection - Off, Enabled Kernel-mode authentication)

SAPIS:

• lms [and all sub applications - i.e. ExportedReports, Reports, Services, Site, etc] (wsAppPool) 
  • Windows (Negotiate, NTLM) (Extended Protection - Off, Enabled Kernel-mode authentication
• Winshuttle Composer (wsAppPool) 
  • Impersonation
  • Windows (Negotiate, NTLM) (Extended Protection - Off, Enabled Kernel-mode authentication)
• WinshuttleServer [Root site] (wsAppPool) 
  • Windows (Negotiate) (Extended Protection - Off, Enabled Kernel-mode authentication)
  • WinshuttleServer [Sub Application] (wsAppPool) 
    • Anon
    • Windows (Negotiate) (Extended Protection - Off, Enabled Kernel-mode authentication)

Does anything jump out at you?

------------------------------
Zachary Daily
Application & Systems Development Engineer
BWX Technologies Inc.
------------------------------

Original Message:
Sent: 04-03-2019 10:39
From: Joshua Whitener
Subject: Workflow Kerberos Authentication

So at least it's making it past RabbitMQ to Worker.

Correct, we don't save Windows Credentials. Our SAP SSO settings matches the active directory username of the current user to the SAP username. By natively supports, I mean there is no additional configurations necessary beyond the manual placing the SNC dll files and configuring SAPIS to use them.

SharePoint websites use the standard SharePoint authentication and providers. (Anonymous, ASP.NET, Forms, Windows {negotiate, NTLM}.

SAPIS's Manager site uses Anon and Windows {negotiate, NTLM}

Based on my experience with Winshuttle infrastructure, I would strongly recommend a single service account for Winshuttle applications and services. I can't list out the 12 pages of constrained delegations, but basically every host has to have constrained delegation to every Winshuttle site and SharePoint web application and every service account has to have the same. With additional SPNs for the Winshuttle service account for the current host plus all Winshuttle sites on that host in HTTP/

I tried attaching a picture of the SAP settings in Foundation, but not sure if will come through.



------------------------------
Joshua Whitener | Technical Advisor
Exxon Mobil Corporation | 8326258441

Original Message:
Sent: 04-03-2019 08:31
From: Joshua Whitener
Subject: Workflow Kerberos Authentication

Hi Zachary,

Your analysis of the call looks right, here's my understanding (SAPIS = WinshuttleServer):

1. User on the workflow initiates a web service call.
2. The workflow engine checks Foundation User Governance through an HTTP call for a user license and the connection string properties for the SAP server as defined on that User Governance site.
3. The workflow engine then calls the particular published web service, which is stored on the SAPIS manager site.
4. The SAPIS manager site puts the job into the RabbitMQ queue.
5. The SAPIS worker services pull from the queue and pass the XML package through RFC to SAP.
6. The SAPIS worker services send the completed package back to the SAPIS manager site.
7. The SAPIS manager site sends the response XML back to the form via the workflow engine.

We use Kerberos as well with SAP SSO. I'm not sure if our SAP SSO is the same as SNC SSO for SAP. We are on v12 which is the first version that natively supports our type of SAP SSO.

As far as I know, there was no additional setup for RabbitMQ. We did have to create SPN's for every Winshuttle account with delegation to every other communicating server's service accounts and we do have to exchange SNC certificates between the Winshuttle SAPIS server and each SAP system.

In your SAPIS worker logs, are you seeing any indication that the web service is getting that far?

------------------------------
Joshua Whitener | Winshuttle Evangelist
Exxon Mobil Corporation | 8326258441

Original Message:
Sent: 04-02-2019 10:35
From: Zachary Daily
Subject: Workflow Kerberos Authentication

We are new to Winshuttle and have Foundation installed with Workflow/Composer.  Currently, we are working on developing our first production workflow application.  The application will be a workflow for creating purchase requisitions.  Being as this will be a widely used application by many users, we want to make the application pretty flexible and easy to use and maintain.  Our development hit a huge snag, though.  We use Kerberos SNC SSO (Single Sign-On) for connecting to SAP.  Therefore, we were hoping to use Kerberos SSO for the Workflow application.  We haven't been able to get it to work, however, and are hoping perhaps someone else has.

We have been told all long that this is possible, but after our most recent encounter with support we were told it's not possible.  We have been given three potential workarounds for this: 1) store and maintain everyone's Windows credentials in Foundation, 2) run the Workflow SAP web services under a dedicated service account, and 3) add credential inputs into each and every workflow.

The first option is not feasible and goes against our security policies, as it requires hundreds of users storing and updating their credentials in SharePoint.

The second option won't work either because it requires a dedicated service account to have full SAP permissions to account for all users who might potentially use the application.  We lose the major selling point of Winshuttle's ability to play nicely with SAP security.

The third option negates the whole point of SSO.

We were hoping someone else has run into this issue and successfully implemented SSO.  Even if it means we move to another form/implementation of SSO, we would consider it.  Kerberos with multiple hops is a very common scenario, so we're trying to understand where the problem is that does not allow for the Kerberos authentication to pass all the way through to SAP.  I'm not sure about the exact architecture of the Workflow application, but my guess is that it works something like this:

1) User connects to Workflow which resides on the Foundation/SharePoint server.
2) Workflow server makes an HTTP call out to integration (or perhaps the call is an AJAX call from the client)
3) Integration Server makes call to SAP

Now the fuzzy part is on the integration server - my guess is that the call from Workflow SharePoint application to the integration server is made via HTTP to the WinshuttleServer website's web service.  From there, I'm guessing there's a means of passing the data to the Worker Windows service.  I know RabbitMQ is used, so I'm guessing perhaps this is the means of passing information between the web service and the windows service using RPC (request/reply), but perhaps I'm wrong?  From there, I'm assuming the windows service reads the message, makes the request to SAP, and returns the data back to the web service on the integration server, which then returns the data back to the Workflow server (or client if it's an AJAX call).  If this is the case, then my assumption is the problem likely lies in the RabbitMQ aspect.  Perhaps they haven't figured out how to pass the ticket through the queue.  From what I know of Kerberos, as long as you can identify the services and dedicate authorized service accounts for them, then you should be able to delegate the hops.  I know there is a Kerberos authentication module for RabbitMQ, but it might not be for hopping the identity from publisher to subscriber, but I would assume you could include the ticket in the message itself.  Perhaps this isn't where the issue lies.  I would like to understand, because it seems like a solvable problem, and right now we cannot move forward with Winshuttle without it being solved.

------------------------------
Zachary Daily
Application & Systems Development Engineer
BWX Technologies Inc.
------------------------------