I recently came across a scenario where I needed to do some maintenance on a client’s instance through our APIs. This particular Composable instance has Windows Authentication enabled, but also has a Forms Authenticated admin account on it. Since windows auth is enabled in IIS, it requires that requests show up with Windows credentials. These windows credentials don’t actually have to have an account (think of when a user wants to register for an account the first time), but just some sort of windows credentials to avoid getting a 401 from IIS.
Composable will look at the auth cookie that is sent with the request to determine the issuing user. This allows you to either login with a Forms Authenticated Account or a Windows Authenticated Account on the same IIS Web Application.
The below code example shows setting up a windows auth WCF channel, but using the FormLoginScope to login and then issue web service calls.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
WebHttpBinding binding = new WebHttpBinding(""); binding.Security.Mode = WebHttpSecurityMode.TransportCredentialOnly; binding.Security.Transport.ClientCredentialType = HttpClientCredentialType.Windows; int[] formIds = { 1, 2, 3 }; ChannelFactory<IFormService> factory = new ChannelFactory<IFormService>(binding, new EndpointAddress(new Uri("http://xxxx/CompAnalytics/Services/FormService.svc"))); factory.Endpoint.Behaviors.Add(new WebScriptEnablingBehavior()); IFormService channel = factory.CreateChannel(); using (FormLoginScope formLogin = new FormLoginScope(new Uri("http://xxxxx/CompAnalytics/"), "admin", "xxxxx")) { using (formLogin.CreateOperationScope((IContextChannel)channel)) { foreach (int formId in formIds) { channel.DeleteForm(formId, false); } } } |
- Deploying Composable Resources via Powershell - December 1, 2022
- Composable APIs via Powershell - December 1, 2022
- Enabling Long Paths in Composable - April 6, 2022
