asp.net authentification contre mvc Shibboleth et autorisation

Question

Où puis-je obtenir des informations sur l'utilisateur actuellement connecté? Autrement dit, comment Shibboleth passer l'information?

Puis-je définir des restrictions sur les actions en utilisant attribut [Authorize] à partir des données acquises à partir Shibboleth?

Answer 1

Shibboleth publie des attributs d'utilisateur associés à sessions en-têtes de requête HTTP, en fonction des noms d'en-tête définis dans l'attribut Politique d'acceptation (de 1.3.x) ou le mappage des attributs (2.x) des dossiers. Ces en-têtes sont transformées en variables CGI en fonction sur les règles de correspondance définies par la spécification CGI.

Vous devriez être au courant de cet avis de sécurité: http://shibboleth.net/community/advisories/secadv_20090615.txt

Answer 2

Je n'ai jamais Shibboleth utilisateur, mais vous pouvez obtenir des informations sur l'utilisateur de la propriété Controller.User. Il retournera un générique principal du thread courant. En utilisant ce principe, vous pouvez vérifier si l'utilisateur est authentifié et obtenir un nom de connexion de l'utilisateur. Cela est dû à la raison pour laquelle l'ouverture de session après un cookie d'authentification est défini et ce cookie contient une quantité limitée d'informations. Et sur chaque demande après l'ouverture de session ce cookie est cochée (si elle existe et valide - utilisateur est authentifié).
Donc, si vous avez besoin des informations spécifiques, vous pouvez charger manuellement un utilisateur (il est préférable d'utiliser le cache ici) et vérifiez ce que vous voulez.
vous pouvez également créer et joindre votre propre principale avec les informations nécessaires pour le fil au démarrage d'une demande (par exemple au démarrage d'une demande charger l'utilisateur de db / cache en utilisant le nom d'utilisateur du principe de base, créer et définir votre propre principale de fil) . Après cela, vous pouvez vérifier toutes les propriétés de l'utilisateur dont vous avez besoin.

Answer 3

Où accorderiez-vous votre principale? Vous dites que le début de la demande, mais si vous ne souhaitez pas que chaque autorisation de demande?

Answer 4

Vous voulez créer une méthode dans Global.asax.cs qui a la signature suivante

protected void Application_PostAuthenticateRequest()
{
    //Your code here.
}

sera appelée automatiquement avant presque tout le reste est fait (MVC appellera cette méthode si elle existe, vous ne devez pas « allumer » partout), ce qui est là que vous devez définir le principal. Par exemple, supposons que vous avez un en-tête appelé RolesHeader qui a une valeur séparées par des virgules des rôles et un autre en-tête appelé UserId qui a (duh) l'ID utilisateur.

Votre code, sans aucune manipulation d'erreur, pourrait ressembler à:

protected void Application_PostAuthenticateRequest()
{
    var rolesheader = Context.Request.Headers["RolesHeader"];
    var userId = Context.Request.Headers["UserId"];
    var roles = rolesheader.Split(',');
    var principal = new GenericPrincipal(new GenericIdentity(userId), roles);
    Context.User = principal;
}

Il est le principal / Identité que l'attribut [Authorize] utilise, pour la mise ici au début du cycle de vie de demande signifie l'attribut [Authorize] fonctionnera correctement.

Le reste de c'est facultative, mais je le recommande:

J'aime créer mes propres classes personnalisées qui mettent en œuvre IPrincipal et IIdentity au lieu d'utiliser la GenericPrincipal et GenericIdentity, donc je peux farcir plus d'informations utilisateur en elle. Mes objets principaux personnalisés et d'identité ont alors des informations beaucoup plus riches, comme les numéros de branche ou adresses e-mail ou autre.

Ensuite, je crée un contrôleur appelé BaseController qui a les éléments suivants

protected new CustomPrincipal User
{
    get
    {
        return (base.User as CustomPrincipal) ?? CustomPrincipal.GetUnauthorizedPrincipal();
    }
}

Cela me permet d'accéder à toutes mes riches, des données personnalisées principales au lieu de simplement ce qui est défini dans IPrincipal. Tous mes vrais contrôleurs héritent alors de BaseController au lieu de directement à partir Controller.

Il est évident que, lorsque vous utilisez un principal personnalisé comme celui-ci, dans la méthode Application_PostAuthenticateRequest (), vous devez créer le Context.User être votre CustomPrincipal au lieu d'un GenericPrincipal.