Autenticazione Sharepoint. Come ottenere cookie SharePoint da ADFS

Question

Codifichiamo un'applicazione Sharepoint, la espandiamo come Provider-hosted, utilizzando il certificato, e ancoriamo il nostro progetto MVC ad esso Espandi tutto ciò sullo stesso IIS di SharePoint espanso.

Attività n. 1: un utente accede a Sharepoint, avvia la nostra applicazione; l'applicazione si avvia senza alcuna richiesta di autorizzazione e ottiene l'utente da Sharepoint si registra nel

Task # 2:. Se la richiesta di servizio Sharepoint è necessario, i nostri registri delle applicazioni in Sharepoint sotto lo stesso nome utente dell'utente connesso in Sharepoint.

Abbiamo provato:

1) Costruire Provider-hosted App, scrivere il nostro MVC in essa, la creazione di un certificato auto-canto, regolando alta di fiducia tra il sito di SharePoint e la nostra MVC.

Abbiamo ottenuto: Se il nostro MVC utilizza l'autenticazione di Windows, poi, quando il trasferimento alla nostra applicazione, il nome utente e la password sono richiesti più volte; inserendoli, è possibile ottenere ClientContext tramite TokenHelper utilizzando il metodo GetS2SClientContextWithWindowsIdentity.

Se l'autenticazione di Windows è disattivata, l'utente non viene registrato nella richiesta, e questo metodo risponde eccezione che l'utente non è connesso.

2) abbiamo installato e regolato ADFS, Sharepoint configurato per il lavoro con ADFS, ha scritto gli indirizzi di SharePoint e la nostra applicazione nella trasmissione del partito trust (in Identifiers and WS-Federtation` passivo Endpoint)

Abbiamo ottenuto: a utente accede in Sharepoint, e durante il trasferimento alla nostra applicazione, il la tter ottiene i dati dell'utente (Reclami)

Così, la prima attività è stata scaricata. Dopo di che, un problema di ottenere l'accesso ai servizi di Sharepoint sotto l'utente autorizzato sorse

Abbiamo cercato di ottenere AccessToken per Sharepoint attraverso rivendicazioni che abbiamo ricevuto Abbiamo cercato di trasferire i seguenti reclami:

nii":"trusted:adfs 
nii":"urn:office:idp:forms:adfs201 //adfs201 - name of our ADFS service 
upn:UserLogin 
emailaddress:UserEmail@domain.kz 

dopo di che, abbiamo chiamato un metodo di rispondere AccessToken secondo le rivendicazioni inseriti

string issuer = string.IsNullOrEmpty(sourceRealm) ? issuerApplication : string.Format("{0}@{1}", issuerApplication, sourceRealm); 
    string nameid = string.IsNullOrEmpty(sourceRealm) ? sourceApplication : string.Format("{0}@{1}", sourceApplication, sourceRealm); 
    string audience = string.Format("{0}/{1}@{2}", targetApplication, targetApplicationHostName, targetRealm); 

    List<JsonWebTokenClaim> actorClaims = new List<JsonWebTokenClaim>(); 
    actorClaims.Add(new JsonWebTokenClaim(JsonWebTokenConstants.ReservedClaims.NameIdentifier, nameid)); 
    if (trustedForDelegation && !appOnly) 
    { 
     actorClaims.Add(new JsonWebTokenClaim(TokenHelper.TrustedForImpersonationClaimType, "true")); 
    }  

    if (addSamlClaim) 
     actorClaims.Add(new JsonWebTokenClaim(samlClaimType, samlClaimValue)); 

    // Create token 
    JsonWebSecurityToken actorToken = new JsonWebSecurityToken(
     issuer: issuer, 
     audience: audience, 
     validFrom: DateTime.UtcNow, 
     validTo: DateTime.UtcNow.AddMinutes(TokenLifetimeMinutes), 
     signingCredentials: SigningCredentials, 
     claims: actorClaims); 

    string actorTokenString = new JsonWebSecurityTokenHandler().WriteTokenAsString(actorToken); 

    if (appOnly) 
    { 
     // App-only token is the same as actor token for delegated case 
     return actorTokenString; 
    } 

    List<JsonWebTokenClaim> outerClaims = null == claims ? new List<JsonWebTokenClaim>() : new List<JsonWebTokenClaim>(claims); 
    outerClaims.Add(new JsonWebTokenClaim(ActorTokenClaimType, actorTokenString)); 

    //**************************************************************************** 
    //SPSAML 
    if (addSamlClaim) 
     outerClaims.Add(new JsonWebTokenClaim(samlClaimType, samlClaimValue)); 
    //**************************************************************************** 

    JsonWebSecurityToken jsonToken = new JsonWebSecurityToken(
     nameid, // outer token issuer should match actor token nameid 
     audience, 
     DateTime.UtcNow, 
     DateTime.UtcNow.AddMinutes(10), 
     outerClaims); 

    string accessToken = new JsonWebSecurityTokenHandler().WriteTokenAsString(jsonToken); 

Poi, si è cercato di ottenere ClientContext, noi ing il metodo:

GetClientContextWithAccessToken(targetApplicationUri.ToString(), accessToken); 

ma abbiamo ottenuto un rapporto di errore:

401 Unauthorized 

ClientID e IssureID sono stati scritti a destra, minuscolo

Dopo di che, abbiamo deciso di richiedere SecurityToken da ADFS con l'aiuto di username e password. Dopo averlo ricevuto, abbiamo richiesto l'autorizzazione in SharepointSTS utilizzando SecurityToken. Quindi, la nostra applicazione ha ottenuto Cookie Sharepoint, che era ancorato alla query (aggiunta in CookieContainer FedAuth) ai servizi di Sharepoint. Quando si attiva ExecutingWebRequest += ClientContext_ExecutingWebRequest, si verifica quanto sopra.

Ma per questo, si dovrebbe usare il username e la password da richiedere ancora una volta.

Nel caso in cui non inoltrare il username e il password, poi risponde con ADFS SecurityToken con i dati degli utenti, sotto il cui nome è stato avviato il pool di applicazioni. E abbiamo bisogno di SecurityToken per l'utente collegato a SharePoint. Abbiamo anche cercato di emettere SecurityToken

var session = System.IdentityModel.Services.FederatedAuthentication.SessionAuthenticationModule.CreateSessionSecurityToken(ClientPrincipals, "context", DateTime.UtcNow, System.DateTime.UtcNow.AddHours(1), true); 
System.IdentityModel.Services.FederatedAuthentication.SessionAuthenticationModule.AuthenticateSessionSecurityToken(session, true); 

Ma la risposta non era lo stesso che ci serviva per l'autorizzazione di SharePoint.

In ADFS in Endpoint, rettifichiamo l'URL; proprio quello che è necessario per l'autorizzazione di SharePoint è inviato a SecurityToken (wresult) tramite query POST. Il problema è che non possiamo ricevere questa query nell'applicazione poiché viene trasmessa nello stato 302 e reindirizzata alla nostra applicazione dal metodo GET, senza SecurityToken con il nostro Cookie.

La domanda è: come è possibile ottenere SecurityToken dell'utente connesso a SharePoint?

Answer 1

Fare un capriccio qui, ma sembra che sia necessario creare un provider di attestazioni, che è una classe che eredita da SPClaimProvider.

Il selettore di persone in sharepoint, che è il controllo che si utilizza per selezionare persone e gruppi, ottiene tutte le persone e i gruppi dai fornitori di attestazioni.

Fuori dalla scatola, esistono le seguenti Provider Claim,

AllUsersClaimProvider FormsClaimsProvider ActiveDirectoryClaimsProvider

Se avete bisogno di ulteriori risoluzione reclami, si deve scrivere uno, che non è così male.

http://msdn.microsoft.com/en-us/library/office/ee537299(v=office.15).aspx

In sostanza, FillClaimsForEntity è dove si può emettere nuove pretese di un Principal identità.

I due sovraccarichi di risoluzione sono dove si vede se c'è una corrispondenza di reclamo per l'input.

E.g. dì che digiti "Bob" nel selettore di persone. Il selettore persone utilizza quindi SPClaimsOperationManager * (dimentica l'ortografia esatta) per chiamare Resolve (input stringa ...) su ogni provider di attestazioni registrato nella farm.

Quindi, diciamo che stiamo parlando del fornitore di attestazioni di moduli. Verificherà se c'è un utente con un nome utente o un indirizzo email che corrisponde a Bob. Per ogni mappatura utente, verrà creata un'entità di selezione e verrà impostato il tipo di attestazione su FormsLogonUser con un valore di bob ecc. E aggiunge ciascuno al risultato.

Quindi quando è finito, vedrai Bob nel People Picker come se fosse stato selezionato, o vedrai Bob con una sottolineatura rossa che significa che erano più partite e che devi scegliere.

Mi sembra che sia necessario crearne uno per consentire al selettore persone di lavorare con le nuove richieste.

Dopo aver effettuato e registrato un fornitore di attestazioni, è possibile utilizzare il selettore persone per concedere l'accesso al sito utilizzando le proprie attestazioni.

Per uno scenario di esempio, una volta ho presentato un fornitore di attestazioni che ha rilasciato attestazioni in base a quali prodotti gli utenti avevano acquistato.

Quindi ho creato un tipo di attestazione di "http://blah.com/schema/claims/product" (può trattarsi di qualsiasi stringa univoca che si desidera sia) E i valori erano cose come "pd.1234.0". Ora in FillClaimsForEntities ho cercato l'utente sul parametro entity nel nostro database per ottenere tutti i loro prodotti. Quindi ho creato una richiesta di prodotto per ciascun prodotto e l'ho aggiunta all'elenco delle richieste.

Quindi in Risolvi cercherò di verificare se un prodotto esiste con un ID o un nome visualizzato che calcola l'input di risoluzione e crea un'entità di selezione se lo ha fatto.

La stessa cosa nella ricerca.

Poi sono entrato nelle pagine dei nostri prodotti e ho concesso l'accesso alla pagina a chiunque avesse la richiesta di quel prodotto utilizzando il selettore di persone. "funziona come selezionare ruoli in autenticazione moduli" tipo di.

Inoltre, è possibile codificare il supporto per Claims Heirarchy e si possono avere più alberi nel selettore persone, 1 albero per ciascun tipo di attestazione con cui si sta lavorando.

E.g. dire "Bob" riporta una persona, un libro e un manager. Potresti avere 3 gerarchie, 1 per le persone, 1 per i libri, 1 per i manager, ecc. E mostrare le affermazioni di quel tipo in quell'albero.

Ho fatto un passo più avanti e ho creato un Access Denied Handler in modo che se un utente ha avuto accesso negato per non essere in quel prodotto rivendicato, lo ha reindirizzato alla pagina di acquisto di quel prodotto.