Hi Patrick,

We have in engineering a similar situation where we want to test our Web API endpoints.

We do this through the same component that drives all authentication flows. The component is known as ServiceReferences and the implementation is in the .net assembly Trisoft.Utilities.ServiceReferences

The internal flow combines active and passive profile.

1. We use active profile and we issue a token through WS Trust. This step is different from the browser's flow because the code actively knows where to get the token from. This is very similar to issuing tokens for wcf proxies. The difference is that the request must be for a bearer token (browser) where for wcf services it is symmetric.
2. We submit the token to the web site as the browser does. We replicated this step by looking in fiddler captures. We extract the cookies from this response.
3. Inject the cookies on every request. If the cookie is valid then the server treats the request as authenticated.

You can simulate multi-user scenarios by grabbing as many cookie sets as you want.

The above sequence is executed from publication manager to show a preview. It authenticates and consumes endpoints both from Architect and Reach using the exact same principal.

The options you have are

• Implement the sequence your selves. We can provide some code samples and additional help. I believe you already have code that issues a token for WCF services. This means that you are very close for step 1. Step 2 is easy and then step 3 is relevant to your code structure.
• Reference the Trisoft.Utilities.ServiceReferences assembly and all its dependencies. Using this assembly provides the implementation for steps 1 and 2 but there are two significant drawbacks.
  • This is an internal purpose assembly so it is eligible for a change without compatibility.
  • The assembly depends on other internal purpose assemblies that your code needs to inherit also. e.g. logging over nlog.

Hi Patrick,

We have in engineering a similar situation where we want to test our Web API endpoints.

We do this through the same component that drives all authentication flows. The component is known as ServiceReferences and the implementation is in the .net assembly Trisoft.Utilities.ServiceReferences

The internal flow combines active and passive profile.

1. We use active profile and we issue a token through WS Trust. This step is different from the browser's flow because the code actively knows where to get the token from. This is very similar to issuing tokens for wcf proxies. The difference is that the request must be for a bearer token (browser) where for wcf services it is symmetric.
2. We submit the token to the web site as the browser does. We replicated this step by looking in fiddler captures. We extract the cookies from this response.
3. Inject the cookies on every request. If the cookie is valid then the server treats the request as authenticated.

You can simulate multi-user scenarios by grabbing as many cookie sets as you want.

The above sequence is executed from publication manager to show a preview. It authenticates and consumes endpoints both from Architect and Reach using the exact same principal.

The options you have are

• Implement the sequence your selves. We can provide some code samples and additional help. I believe you already have code that issues a token for WCF services. This means that you are very close for step 1. Step 2 is easy and then step 3 is relevant to your code structure.
• Reference the Trisoft.Utilities.ServiceReferences assembly and all its dependencies. Using this assembly provides the implementation for steps 1 and 2 but there are two significant drawbacks.
  • This is an internal purpose assembly so it is eligible for a change without compatibility.
  • The assembly depends on other internal purpose assemblies that your code needs to inherit also. e.g. logging over nlog.