Layer7 API Management

Expand all | Collapse all

HTTP Route Assertion fails with Windows Integrated Authentication

  • 1.  HTTP Route Assertion fails with Windows Integrated Authentication

    Posted 01-19-2018 09:33 AM

    Hello,

     

    Using CA API Gateway Version 9.2 CR7, I'm unable to use the HTTP(S) Route Assertion with Windows Integrated Authentication. I was wondering if anyone else ran into similar problems.

     

    I currently am trying to publish a Web API that contains the following Policy Assertions. :

    1. Require Windows Integrated Authentication Credentials
    2. Route via HTTP(S) with the following Authentication selections.
      1. Use Windows Integrated
      2. Use Delegated Credentials

    The URL that I'm performing the HTTP GET to in the Route Assertion is configured to use Windows Integrated Authentication as it is a ASP.NET Application hosted in IIS 8. 

     

    This is where I'm running into issues. The HTTP(S) Route Assertion is failing when I make these selections. Looking in the logs I'm seeing the following:

    2018-01-19T09:10:14.737-0500 INFO    10121 com.l7tech.server.message: Processing request for service: AuthWSTest [/authws]

    2018-01-19T09:10:14.738-0500 WARNING 10121 com.l7tech.server.policy.assertion.ServerHttpRoutingAssertion: 4043: Routing with Kerberos ticket failed with: Credentials for delegation not found

    2018-01-19T09:10:14.738-0500 WARNING 10121 com.l7tech.server.MessageProcessor: 3016: Request routing failed with status 601 (Error in Assertion Processing)

     

    Using the Service Debugger, I've verified that the kerberos.data and kerberos.realm context variables are being populated as seen here:

     

    When making the call via Fiddler I can see API Gateway return the initial 401 Status code with the Authorization: Negotiate header in the Response Headers. Additionally, I can see the client including the Authorization: Negotiate header in the Request after it receives the challenge from the API Gateway. This seems to indicate that Windows Integrated Authentication is working:



  • 2.  Re: HTTP Route Assertion fails with Windows Integrated Authentication

    Posted 01-21-2018 05:33 PM

    Dear mrutherford ,

    Did you run the Manage Kerberos Configuration task and import the keytab into the Kerberos Configuration dialog?

    Please refer to Manage Kerberos Configuration - CA API Gateway - 9.2 - CA Technologies Documentation , section "Authenticating a Client via Kerberos" shows the 5 steps to use delegated credentials.

     

    Regards,

    Mark



  • 3.  Re: HTTP Route Assertion fails with Windows Integrated Authentication

    Posted 01-22-2018 11:45 AM

    Hi Mark,

     

    Yes I have imported the keytab file into API Gateway. API Gateway indicates that the keytab file is valid as well. 



  • 4.  Re: HTTP Route Assertion fails with Windows Integrated Authentication

    Posted 01-22-2018 05:05 PM

    Are the request URI, routing URI in the same domain?

     

    As per the document I provided,

    "

    Require Windows Integrated Authentication Credentials Assertion

    For this assertion, the CA API Gateway will use the request URI to determine which principal in the keytab will be used to handle the Windows authentication.


    Route via HTTP(S) Assertion
    For this assertion, the CA API Gateway will use the routing URI to determine which principal in the keytab will be used to hand the Windows authentication. 

    "



  • 5.  Re: HTTP Route Assertion fails with Windows Integrated Authentication

    Posted 01-23-2018 09:03 AM

    Yes, the initial request to API Gateway and the request to the URL with the Route Assertion are using the same domain and are on the same intranet.



  • 6.  Re: HTTP Route Assertion fails with Windows Integrated Authentication

    Posted 12-21-2018 04:54 PM
      |   view attached

    Good afternoon,

     

    There are a few reasons that this could fail:

    1) The keytab account does not have delegation enabled with at least Trust this user for delegation to any service which is wide open or what is shown below as it is more security conscience. 

    2) Removal of the Authorization header from the original call as the default for the HTTP Routing assertion is to pass through all header which would create a duplicate Authorization header being sent. Add in a Manage Transport Properties/Headers.

     

     

    I've attached a sample policy that works on version 9.3 of the Gateway.

     

    Sincerely,

     

    Stephen Hughes

    Broadcom Support

    Attachment(s)