Ich muss eine programmgesteuerte Verbindung zum SharePoint-Server eines Kunden herstellen, der OKTA zur Authentifizierung verwendet. Ich habe es gesehenPos, das vielversprechend aussah, aber scheinbar keinen gültigen Sitzungscookie von OKTA zurückerhält.

Ich kann den / api / v1 / authn-Endpunkt erfolgreich aufrufen und ein sessionToken zurückerhalten, aber wenn ich mich umdrehe und / api / v1 / sessions? AdditionalFields = cookieToken mit diesem Sitzungstoken aufrufe, erhalte ich immer ein 403-Forbidden, with der folgende json:

{ 
"errorCode": "E0000005", 
"errorSummary": "Invalid Session", 
"errorLink": "E0000005", 
"errorId": "oaew0udr2ElRfCnZvBFt075SA", 
"errorCauses": [] 
}

Angenommen, ich kann dieses Problem lösen, ich bin mir nicht sicher, welche URL ich mit dem cookieToken aufrufen soll. Handelt es sich bei der URL um einen OKTA-Endpunkt, der zu SharePoint umgeleitet wird, oder handelt es sich um einen SharePoint-Endpunkt, der die Sitzung mit dem Cookie einrichtet?

Aktualisieren Ich kann diesen Okta-Endpunkt aufrufen -> / api / v1 / sessions? AdditionalFields = cookieToken mit meinen Benutzeranmeldeinformationen als json

{ 
"username": "[email protected]",
"password": "P@ssw0rd"
}

Und ich kann ein einmaliges Cookie-Token abrufen, das mit diesem Link zum Starten einer SAML-Sitzung in einem Browser verwendet werden kann:

https://[mydomain].okta.com/login/sessionCookieRedirect?redirectUrl=[sharepoint site url]&token=[cookie token]

Das funktioniert in einem Browser, der Benutzer wird automatisch authentifiziert und landet in SharePoint. Es scheint jedoch, dass diese Sitzung "Setup" zumindest teilweise durch Javascript erreicht wird, da das Ausführen des gleichen Links in einem programmgesteuerten HTTP-Client (wie Apache HTTP Client) nicht funktioniert. Der http-Client wird über mehrere Weiterleitungen gesendet und landet auf der SharePoint-Website, der Benutzer ist jedoch nicht authentifiziert. Die Antwort lautet 403 - Verboten mit den folgenden Headern:

403 VERBOTE

Content-Type -> text/plain; charset=utf-8
Server -> Microsoft-IIS/8.5
X-SharePointHealthScore -> 0
SPRequestGuid -> 0ecd7b9d-c346-9081-cac4-43e41f3b159a
request-id -> 0ecd7b9d-c346-9081-cac4-43e41f3b159a
X-Forms_Based_Auth_Required -> https://[sharepoint site]/_login/autosignin.aspx?ReturnUrl=/_layouts/15/error.aspx
X-Forms_Based_Auth_Return_Url -> https://[sharepoint site]/_layouts/15/error.aspx
X-MSDAVEXT_Error -> 917656; Access denied. Before opening files in this location, you must first browse to the web site and select the option to login automatically.
X-Powered-By -> ASP.NET
MicrosoftSharePointTeamServices -> 15.0.0.4709
X-Content-Type-Options -> nosniff
X-MS-InvokeApp -> 1; RequireReadOnly
Date -> Fri, 13 May 2016 15:02:38 GMT
Content-Length -> 13

Ich frage mich, ob dies eine verlorene Ursache ist, dass OKTA oder SharePoint keine programmatische Authentifizierung über SAML unterstützen.