Byliśmy udane w użyciu OData v8.1 końcowym w 2016 do impersonate a user.jak personifikować użytkownika poprzez OData
Należy pamiętać, że prośba jest przeznaczony przepływu: Postman -> host_lokalny Microservice -> CRM
Przykład wniosku roboczego od Postman -> CRM (bezpośrednio, bez przechodzenia przez microservice)
Accept:application/json
Content-Type:application/json; charset=utf-8
OData-MaxVersion:4.0
OData-Version:4.0
MSCRMCallerID:d994d6ff-5531-e711-9422-00155dc0d345
Cache-Control:no-cache
Przeciwko OData końca Temperatura: ..../api/data/v8.1/leads
Zauważ, że ta odniosła sukces tylko wtedy, gdy wydane bezpośrednio przed końcowym OData V8.1 poprzez postman.
Podczas próby zrobienia tego samego, mając usługę uruchomioną lokalnie (Listonosz -> Usługa LocalHost -> CRM), to się nie udaje i po prostu ignoruje ??? nagłówek MSCRMCallerID.
Po zbadaniu nagłówków, które zostały przekazane do localhost Microservice od Postman, wniosek, jako zbadane przez debugger w VS 2017:
{Method: POST, RequestUri: 'https://.../api/data/v8.1/leads', Version: 1.1, Content: System.Net.Http.StringContent, Headers:
{
OData-Version: 4.0
OData-MaxVersion: 4.0
MSCRMCallerID: D994D6FF-5531-E711-9422-00155DC0D345
Cache-Control: no-cache
Accept: application/json
Content-Type: application/json; charset=utf-8
}}
Rekord jest tworzony pomyślnie, jednak na polu CreatedBy jest usługa nazwa użytkownika NIE nazwa użytkownika MSCRMCallerID (d994d6ff-5531-e711-9422-00155dc0d345), a pole CreatedOnBehalf jest puste.
Co robimy źle?
Jak możemy uzyskać to podszywanie się od naszych usług?
EDIT + Więcej informacji
Należy pamiętać, że wierzę, że podaję wszystkie istotne informacje, ale jeśli nie, proszę dać mi znać, co inne wejście powinien zapewnić w tej sprawie .
Co próbowałem?
- zmienił kolejność nagłówków
- grał z przypadku nagłówków
- zapewniony że GUID jest poprawna od użytkownika do podszywania
- zapewnić, że użytkownik ma zarówno delegata i sys rolę administratora (chociaż nie ma to znaczenia, ponieważ działa to podczas wykonywania żądania bezpośrednio przed punktem końcowym crm odata, a nie punktem końcowym, który nasza usługa wystawia
- próbowały wykonać żądanie zarówno z https, jak i http
- skrzypek ślad jak pokazano poniżej
Należy pamiętać, że ten ślad Skrzypek ma śladu pokazując Postman -> Microservice żądania. To nie pokazuje komunikacji z localhost microservice do CRM. (nie jestem pewien dlaczego, może dlatego, że jest szyfrowana)
POST https://localhost:19081/.....Leads/API/leads HTTP/1.1
Host: localhost:19081
Connection: keep-alive
Content-Length: 84
Cache-Control: no-cache
Origin: chrome-extension://aicmkgpgakddgnaphhhpliifpcfhicfo
MSCRMCallerID: D994D6FF-5531-E711-9422-00155DC0D345
X-Postman-Interceptor-Id: d79b1d2e-2155-f2ec-4ad7-e9b63e7fb90d
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.113 Safari/537.36
Content-Type: application/json; charset=UTF-8
Accept: */*
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.8
Cookie: ai_user=Ka2Xn|2017-05-25T17:30:57.941Z
{
"subject": "created by mscrmcaller user2: d994d6ff-5531-e711-9422-00155dc0d345"
}
@Ram zasugerował, że korzystanie z usługi organizacji w celu uwierzytelnienia, jest to opcja, zważywszy realizujemy przeciwko Web API? Czy żądany token nadal będzie ważny. (Należy pamiętać, że może to być głupie pytanie, a powodem jest to, że nie rozumiem, jak działa uwierzytelnianie).
Poniżej znajduje się fragment kodu z jak jesteśmy autentyczną obecnie na każde wezwanie:
//check headers to see if we got a redirect to the new location
var shouldAuthenticate = redirectUri.AbsoluteUri.Contains("adfs/ls");
if (!shouldAuthenticate)
{
return;
}
var adfsServerName = redirectUri.Authority;
var queryParams = HttpUtility.ParseQueryString(redirectUri.Query);
ServicePointManager.ServerCertificateValidationCallback +=
(sender, cert, chain, sslPolicyErrors) => true;
WSTrustChannelFactory factory = null;
try
{
// use a UserName Trust Binding for username authentication
factory = new WSTrustChannelFactory(
new UserNameWSTrustBinding(SecurityMode.TransportWithMessageCredential),
$"https://{adfsServerName}/adfs/services/trust/13/usernamemixed")
{
Credentials =
{
UserName =
{
UserName = $"{credential.Domain}\\{credential.UserName}",
Password = credential.Password
}
},
TrustVersion = TrustVersion.WSTrust13
};
var rst = new RequestSecurityToken
{
RequestType = RequestTypes.Issue,
AppliesTo = new EndpointReference(_client.BaseAddress.AbsoluteUri),
TokenType = "urn:oasis:names:tc:SAML:1.0:assertion",
KeyType = KeyTypes.Bearer
};
var channel = factory.CreateChannel();
channel.Issue(rst, out RequestSecurityTokenResponse rstr);
var fedSerializer = new WSFederationSerializer();
var rstrContent = fedSerializer.GetResponseAsString(rstr, new WSTrustSerializationContext());
// construct a authentication form
var crmauthenticaionPostDictionary = new Dictionary<string, string>
{
{"wa", queryParams["wa"]},
{"wresult", rstrContent},
{"wctx", queryParams["wctx"]}
};
// post the authentication form to the website.
var crmAuthorizationPostResponse = _client.PostAsync(_client.BaseAddress.AbsoluteUri, new FormUrlEncodedContent(crmauthenticaionPostDictionary)).Result;
var crmAuthorizationPostResponseString = crmAuthorizationPostResponse.Content.ReadAsStringAsync().Result;
//we should be authenticated here
if (
!(
// we are correctly authorized if we got redirected to the correct address that we
// were trying to reach in the first place.
crmAuthorizationPostResponse.StatusCode == HttpStatusCode.Redirect
&& crmAuthorizationPostResponse.Headers.Location == authenticationTestUri
)
)
{
throw new Exception("ADFS Authentication to CRM failed.");
}
Czy udało Ci się zweryfikować nagłówek w zakładce sieci skrzypka lub przeglądarki? –
@ArunVinoth dziękuję za twoje pytanie, zaktualizowałem pytanie –
czy byłeś w stanie to rozwiązać? –