Autentica nei servizi? O in un endpoint che espone i servizi?

Question

Autentica nei servizi? O in un endpoint che espone i servizi?

#1 da (1 voti)
#2 da (1 voti)

2

Quando sono responsabile, di solito modifico i servizi separatamente dagli endpoint. Ad esempio: Company.Project.Domain.dll ha tutta la logica necessaria per completare i servizi per quel dominio. Per accedervi, fai riferimento a quella libreria o, se esponi i servizi tramite un endpoint , puoi toccare Company.Project.Endpoint all'URL: api.wutevz.com/blog / Messaggio /

Cito quanto sopra perché ho (apparentemente sfortunatamente, ma forse sono quello sbagliato) visto la maggior parte dei servizi / domini creati direttamente all'interno di un progetto endpoint (come WCF o Web API). E sapere che la mia configurazione è la chiave della mia domanda. Inoltre, se separare la logica dall'endpoint è strano, sentitevi liberi di intervenire. Mentre penso che separarli sia corretto, sono stanco di molti anni di consulenza e vederli uniti.

La domanda, se la mia metodologia è valida, è: Dove dovrebbe Autenticazione Live nel back-end? Questo non è correlato ad altre domande che chiedono se dovrebbe essere nel back-end contro il client. La mia domanda è: sugli endpoint o sui servizi?

Quindi la mia API Web ha questo Endpoint:

[HttpPost]
//[AuthenticatePlz]
public HttpResponseMessage Message([FromBody] string contents){
    _service.AddMessage(contents);
}

E alcuni servizi di dominio hanno il metodo che fa il vero biz:

//[AuthenticatePlz]
public void AddMessage(string contents) {
    // probably do some content checks or something and save the message
}

Non esagerare nel vedere se gli Aspetti vengono usati, o qualche middleware Owin, o la Linea 1 del metodo è una chiamata Auth, o qualche altra implementazione orribile. L'obiettivo è: il punto di intercettazione, dove è richiesta l'autenticazione, deve vivere sull'endpoint o sul metodo di servizio?

c# authentication domain-model services

posta Suamere 14.07.2015 - 15:39

fonte

2 risposte

Leggi altre domande sui tag c# authentication domain-model services

La funzione utilizza la comprensione degli elenchi python, senza stato? Come gestisco le chiamate di terze parti a esecuzione prolungata dal backup della coda dei messaggi?

score 1 · Answer 1

Idealmente l'autenticazione non dovrebbe avvenire né nel punto finale né nel servizio. Un modulo in IIS o un server proxy sarebbe il migliore, o un plugin per il framework dell'applicazione. Se devi mescolare i due metterei l'autenticazione nel punto finale. Un oggetto "servizio" dovrebbe presupporre che tu abbia le autorizzazioni per usarlo in modo da mantenere la massima riusabilità.

In realtà il punto finale dovrebbe anche presupporre che tu abbia il permesso di operare su di esso. Qualcosa di più in alto nello stack dovrebbe impedire l'esecuzione del tuo oggetto endpoint se l'autenticazione fallisce. In questo modo, le modifiche alle autorizzazioni o agli schemi di autenticazione non richiedono modifiche al tuo endpoint o livello di servizio.

score 1 · Answer 2

Se non mi sbaglio, ASP.NET Web Api gestisce l'autenticazione utilizzando IPrincipal interfaccia.

A principal object represents the security context of the user on whose behalf the code is running, including that user's identity (IIdentity) and any roles to which they belong.

Questo oggetto è fondamentalmente un insieme di Reclami che definisce e descrive l'utente corrente. Cioè il suo nome utente, email e persino ruoli.

Se stai utilizzando un middleware o meno, queste affermazioni devono essere impostate in modo che l'autenticazione possa essere integrata nella pipeline di IIS.

In un esempio di servizio web come il tuo, queste affermazioni vengono comunemente decodificate da un token di autenticazione. Questo token viene inviato insieme alla richiesta dell'utente e pertanto deve essere gestito a livello di endpoint (Controller).

Il tuo servizio di dominio non deve controllare il contesto della richiesta corrente, né sapere che viene chiamato da un servizio web o da un client desktop.