web-dev-qa-db-fra.com

La déconnexion de Cognito ne fonctionne pas comme documenté

J'ai un pool d'utilisateurs Cognito configuré avec un fournisseur d'identité SAML (ADFS) et je peux le signer en tant qu'utilisateur fédéré (AD) mais la déconnexion ne fonctionne pas.

Suite à la documentation , je fais une demande GET à https://my-domain.auth.us-west-2.amazoncognito.com/logout?client_id=63...ng&logout_uri = http:% 2F% 2Fyahoo.com (en utilisant un uri de déconnexion public), de mon client (une application AngularJS 1.x), et je récupère un 302 avec un emplacement en-tête comme

https://my-domain.auth.us-west-2.amazoncognito.com/login?client_id=63...ng&logout_uri=http:%2F%2Fyahoo.com

(En fait, je vois 2 demandes comme ci-dessus).

Lorsque je me reconnecte (via ADFS), il ne demande pas mes informations d'identification AD, c'est-à-dire que je ne suis pas déconnecté.

Mon groupe d'utilisateurs est configuré comme décrit ici (voir l'étape 7), où le Activer le flux de déconnexion IdP est vérifié, ce qui est censé également déconnecter l'utilisateur d'ADFS.

Aucune suggestion? Merci.

General
-------
Request URL: https://my-domain.auth.us-west-2.amazoncognito.com/logout?client_id=63...ng&logout_uri=http:%2F%2Fyahoo.com  
Request Method: GET  
Status Code: 302  
Remote Address: 54.69.30.36:443  
Referrer Policy: no-referrer-when-downgrade  

Response Headers
----------------
cache-control: private  
content-length: 0  
date: Fri, 20 Apr 2018 21:31:12 GMT  
expires: Thu, 01 Jan 1970 00:00:00 UTC  
location: https://my-domain.auth.us-west-2.amazoncognito.com/login?client_id=63...ng&logout_uri=http:%2F%2Fyahoo.com  
server: Server  
set-cookie: XSRF-TOKEN=...; Path=/; Secure; HttpOnly  
set-cookie: XSRF-TOKEN=""; Expires=Thu, 01-Jan-1970 00:00:10 GMT; Path=/; Secure; HttpOnly  
status: 302  
strict-transport-security: max-age=31536000 ; includeSubDomains  
x-content-type-options: nosniff  
x-frame-options: DENY  
x-xss-protection: 1; mode=block  

Request Headers
---------------
:authority: my-domain.auth.us-west-2.amazoncognito.com  
:method: GET  
:path: /logout?client_id=63...ng&logout_uri=http:%2F%2Fyahoo.com  
:scheme: https
accept: application/json, text/plain, */*  
accept-encoding: gzip, deflate, br  
accept-language: en-US,en;q=0.9  
authorization: Bearer eyJra...  
cache-control: no-cache  
Origin: https://localhost:8443  
pragma: no-cache  
referer: https://localhost:8443/logout  
user-agent: Mozilla/5.0...
amazon-web-servicesadfscognito
10
sharpthor

Cette redirection se produit chaque fois que logout_uri le paramètre ne correspond pas exactement à ce qui est répertorié parmi RL de déconnexion dans les pools d'utilisateurs AWS Cognito Paramètres du client d'application configuration.

Cognito permet la déconnexion avec logout_uri ou avec les mêmes arguments que la connexion (c'est-à-dire redirect_uri et response_type) pour vous déconnecter et ramener l'utilisateur à l'écran de connexion. Il semble que chaque fois que logout_uri n'est pas valide, il suppose le flux de reconnexion, effectue cette redirection, puis signale une erreur concernant les arguments de connexion manquants.

En ce qui concerne SAML, je ne sais pas, mais deviner que cela ne fonctionne pas car il y avait en fait une erreur, mais pas correctement signalée.

5
DS.

Le /logout endpoint déconnecte l'utilisateur. Il ne prend en charge que HTTPS GET . Ça fonctionne

Exemples de demandes - Déconnexion et redirection vers le client

Il efface la session existante et redirige vers le client. Les deux paramètres sont obligatoires.

GET https://<YOUR DOMAIN NAME>/logout?
client_id=xxxxxxxxxxxx&
logout_uri=com.myclientapp://myclient/logout

Assurez-vous également que l'URL de déconnexion est identique à l'URL DE DÉCONNEXION dans l'AWS Cognito APP également.

pour plus d'informations, reportez-vous à AWS LOGOUT Endpoint

4
Ak S
@RequestMapping(value = "/logout", method = RequestMethod.GET)
public void logout(HttpServletRequest request, HttpServletResponse response) {
    LOGGER.info("Logout controller");
    try {
        Cookie awsCookie = new Cookie("AWSELBAuthSessionCookie-0", "deleted");
        awsCookie.setMaxAge(-1);
        awsCookie.setPath("/");
        response.addCookie(awsCookie);
        Properties appProperties = new Properties();
        applicationPropertyConfigurer.loadProperties(appProperties);
        response.sendRedirect(appProperties.getProperty("logout.url"));
        response.setHeader("Cache-Control", "no-cache, no-store, must-revalidate, max-age=0");
        response.setHeader("Pragma", "no-cache");
        response.setDateHeader("Expires", -1);
        request.getSession().invalidate();

    } catch (IOException e) {
        LOGGER.error("Exception in redirecting to logout.url URL", e);
    }

}

//https:/domain_name.auth.us-west-x.amazoncognito.com/logout?response_type=code&client_id=&redirect_uri=redirect_uri_should_be_present_in_cognito_user_pool_Callback URL & state = STATE & scope = openid

0
pramod sable

Enfin, j'ai pu résoudre ce problème. J'ai trouvé la cause réelle du problème dans l'observateur d'événements de mon serveur Windows 2012 R2. Il indique les détails suivants sur le flux de déconnexion échoué.

La demande de déconnexion unique SAML ne correspond pas au participant à la session connecté. Demandeur: urn: Amazon: cognito: sp: userpoolid Identificateur du nom de la demande: Format: urn: oasis: noms: tc: SAML: 2.0: format nameid: persistant, NameQualifier: SPNameQualifier:, SPProvidedId: Participants à une session connectée: Nombre: 1, [Émetteur: urn: Amazon: cognito: sp: userpoolid, NameID: (Format:, NameQualifier: SPNameQualifier:, SPProvidedId:)]

Action de l'utilisateur Vérifiez que l'approbation du fournisseur de revendications ou la configuration d'approbation de la partie de confiance est à jour. Si l'identifiant de nom dans la demande est différent de l'identifiant de nom dans la session uniquement par NameQualifier ou SPNameQualifier, vérifiez et corrigez la règle d'émission de stratégie d'identifiant de nom à l'aide du composant logiciel enfichable Gestion AD FS 2.0).

L'erreur indique clairement que l'identifiant de nom dans la demande est différent de l'identifiant de nom dans la session uniquement par NameQualifier. J'ai corrigé cette erreur dans l'onglet d'émission des réclamations des fiducies de parties de confiance en ajoutant la règle ci-dessous. La règle ci-dessous remplace l'utilisateur @ myadfsdomain par simplement user lors de l'émission de la réclamation.

c:[Type == "http://schemas.Microsoft.com/ws/2008/06/identity/claims/windowsaccountname"]
 => issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = RegExReplace(c.Value, "(?i)^myadfsdomain*\\", ""), ValueType = c.ValueType, Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"] = "urn:oasis:names:tc:SAML:2.0:nameid-format:persistent");

En plus de cela, j'ai oublié de vérifier le flux de déconnexion activé dans la configuration cognito qui a causé le problème. La déconnexion a commencé à fonctionner de manière transparente pour moi.

0
Keerthikanth Chowdary