Comportement des navigateurs d'applications mobiles avec les sessions Google et le sélecteur de compte

Question

Problème : J'essaie de créer un SSO entre l'application mobile et le navigateur.

Ce que nous avons :

Nous avons une application mobile ionique avec "Connexion avec Google" utilisant l'authentification OAuth 2.0. Nous avons plusieurs applications internes qui fonctionnent sur OAuth2 et SAML, et nous avons donc activé le SSO pour GSuite afin que toutes les applications fonctionnent de manière transparente avec un seul login et mot de passe. Maintenant, lorsque nous appuyons sur le bouton "Connexion avec Google",

1. Ouvre la page de connexion SSO dans une application de navigateur. Nous avons activé le SSO et nous avons donc défini login_hint, ce qui nous permet d'accéder directement à la page de connexion SSO. page de connexion SSO.

2. L'utilisateur saisit son adresse électronique et son mot de passe et il est redirigé vers le site Web de la Commission européenne. redirect_uri après une authentification réussie avec le code OAuth 2.

3. Le redirect_uri est fait de telle sorte que lorsque l'url est déclenchée, il redirige à nouveau vers notre application Android avec le code OAuth 2 param et puis nous extrayons l'access_token et le useremail à partir de token et userinfo endpoints.

4. Sur la base de l'autorisation, le tableau de bord indique les liens vers nos services internes. internes. qui fonctionne avec l'authentification Google SAML 2.0 ou OAuth2.

Ce qui est attendu :

Lorsque l'utilisateur clique sur l'un des liens SAML/OAuth 2 à partir du tableau de bord de l'application mobile, nous ouvrons ce lien dans l'application du navigateur et il devrait être automatiquement connecté à cette application et nous conduire à la page de destination car nous avons déjà défini les sessions Google à l'étape #a.

Les choses qui s'écartent des attentes :

• Lorsque nous essayons d'accéder aux applications SAML/OAuth, le sélecteur de compte s'affiche alors qu'un profil est défini dans le navigateur Chrome, ce qui donne la liste de tous les comptes synchronisés dans l'appareil mais pas celui avec lequel l'utilisateur s'est connecté. Il devrait afficher ce compte ou se connecter directement et afficher la page de destination. Cela ne se produit pas lorsque nous n'avons pas de profil défini dans Chrome.
• Les sessions dans tous les navigateurs sont tuées automatiquement lorsque nous faisons ce qui suit et demande donc à nouveau les informations d'identification.
  • fermer l'onglet du navigateur (parfois).
  • supprimer le navigateur du plateau des applications récentes (la plupart du temps)
  • redémarrer l'appareil (toujours)

Vous voulez comprendre comment et quand les sessions sont créées et détruites automatiquement dans Google Chrome sur les téléphones portables ?

Existe-t-il un moyen de conserver la session intacte ? |Existe-t-il un moyen de contourner le sélecteur de compte qui affiche les comptes synchronisés avec le téléphone ?

Mise à jour

Capable de comprendre une observation étrange : Nous avons désactivé le SSO pour que l'écran de connexion de Google apparaisse. Avec cela, tout fonctionne bien. Les sessions ne sont pas détruites même si l'on redémarre le navigateur ou le téléphone, qu'il s'agisse d'Android ou d'iOS.

Le problème se situe donc dans le SSO que nous avons conçu. Nous n'arrivons pas à comprendre ce qui doit être défini dans le XML SAML que nous envoyons à l'URL ACS de Google.

Answer 1

1. Vous voulez comprendre comment et quand les sessions sont créées et détruites automatiquement dans Google Chrome sur les téléphones mobiles ?

Je pense que Google Chrome fonctionne sur les téléphones mobiles de la même manière que sur les ordinateurs, les sessions sont donc créées et supprimées à l'aide de la commande HTML5 sessionStorage , utilisateur configuration et dispositif politiques :

Il existe deux types de Stockage sur le Web s localStorage, et le sessionStorage. [ ] localStorage persiste sur différents onglets ou fenêtres, fermons le navigateur, conformément à la politique de sécurité du domaine et à la politique de sécurité de l'utilisateur. les choix de l'utilisateur concernant la limite des quotas.

Aussi, il est important de savoir comment Chrome enregistre et synchronise les mots de passe :

Comment Chrome enregistre et synchronise les mots de passe (sur l'ordinateur et les appareils Android) d et les utiliser sur plusieurs appareils. Lorsqu'ils sont synchronisés, les mots de passe peuvent être utilisés sur Chrome sur tous vos appareils, et sur certaines applications de votre appareil Android sur votre appareil Android.

Vos mots de passe sont enregistrés dans votre Google Ac suivantes sont vraies :

• Vous êtes connecté à Chrome et vous synchronisez les mots de passe.
• Vous utilisez Smart Lock pour les mots de passe sur Android

Sinon, vos mots de passe sont uniquement stockés dans Chrome sur votre ordinateur ou votre appareil Android.

Comment Chrome enregistre et synchronise les mots de passe (dans les appareils iPhone et iPad) dépend de votre volonté de les stocker et de les utiliser sur plusieurs appareils.

Vos mots de passe sont enregistrés sur votre compte Google si vous êtes Chrome et que vous synchronisez vos mots de passe.

Sinon, vos mots de passe ne sont stockés que sur Chr iPad.

---

2. Existe-t-il un moyen de conserver la session intacte ?

Je ne suis pas compétent/intéressé par le développement iOs ou HTML5, mais j'ai essayé quelque chose de similaire pour Android et un ancien domaine Google Apps quand Google a lancé Smart Lock pour les mots de passe sur Android :

Sauvegarde et récupération programmées des données automatiquement les utilisateurs sur tous les périphériques et sites Web dans Chrome.

Nota: SSL est nécessaire sur votre serveur pour Permettre la connexion automatique à travers les applications et les sites web

Le verrou intelligent pour les mots de passe et API Comptes connectés facilite l'enregistrement et la récupération des informations d'identification pour votre application et le site associé.

Vous pouvez Gestion de plusieurs justificatifs d'identité enregistrés y supprimer manuellement les informations d'identification stockées

Lorsque la saisie de l'utilisateur est nécessaire pour sélectionner un c méthode getStatusCode() renvoie RESOLUTION_REQUIRED. Dans ce cas, il faut appeler la méthode startResolutionForResult() de l'objet d'état pour inviter l'utilisateur à l'utilisateur à choisir un compte. Ensuite, récupérez le compte choisi par l'utilisateur de l'utilisateur à partir de la méthode onActivityResult() de l'activité en passant le code Credential.EXTRA_KEY à la méthode getParcelableExtra().

Et Se connecter en utilisant des jetons d'identification disponible lorsque l'ID utilisateur d'un objet Credential correspond à l'ID utilisateur d'un compte Google connecté sur le périphérique.

Comment le mettre en œuvre et des scénarios utiles pour test y vérifier dans les réponses SO connexes.

---

3. Existe-t-il un moyen de contourner le sélecteur de compte qui affiche les comptes synchronisés avec le téléphone ?

Utiliser Google Sign-In avec les applications informatiques

Mettez l'application sur une liste blanche afin que vos utilisateurs écran de confirmation lorsqu'ils se connectent. [ ] étapes suivantes ( point 4 : transmettre le domaine Google for Work du compte au serveur d'authentification, afin que seuls les comptes de ce domaine s'affichent lors de la connexion. ), garantit que les utilisateurs de votre application informatique peuvent s'identifier automatiquement. Pour mettre votre application sur une liste blanche :

• Ouvrez le Console d'administration de G Suite .
• Cliquez sur l'icône Sécurité, puis sur Afficher plus > Paramètres avancés > Gérer l'accès client API.

• Saisissez l'identifiant client OAuth que vous avez enregistré pour l'application. A .apps.googleusercontent.com.
• Dans le champ API Scopes, tapez la chaîne suivante : https://www.googleapis.com/auth/plus.me,https://www.googleapis.com/auth/userinfo.email
• Si votre application doit demander des scopes supplémentaires pour accéder aux API de Google, indiquez-les ici.
• Cliquez sur Autoriser. La liste blanche prendra effet dans environ 30 minutes.

Nota: La liste blanche ne fonctionnera pas si l'application lance le flux OAuth/Open ID Connect et inclut les paramètres suivants hors ligne o prompt . Ces paramètres ne sont généralement pas nécessaires pour les applications informatiques.

Force/bypass google account chooser dans les URLs d'autorisation OAuth2

Le paramètre suivant est pris en charge dans les URL d'autorisation OAuth2 : prompt

Actuellement, il peut avoir les valeurs ' none ', ' select_account ', et ' consent '.

aucun : Google n'affichera pas d'interface utilisateur doit se connecter, ou sélectionner un compte en cas de connexion multiple, ou encore consentir si première approbation. Il peut être exécuté dans une i-frame invisible pour obtenir un jeton de la part des utilisateurs précédemment autorisés avant de décider, par par exemple, de rendre un bouton d'autorisation.

consentement : forcera l'affichage de la page d'approbation même si l'utilisateur a déjà autorisé votre application. Peut être utile dans quelques cas particuliers, par exemple, si vous avez perdu le refresh_token de l'utilisateur, car Google n'émet des refresh_tokens que pour les actions de consentement explicite.

compte_sélectionné : Le sélecteur de compte s'affichera, même si un seul utilisateur est connecté. il n'y a qu'un seul utilisateur connecté, comme vous l'avez demandé.

select_account peut être combiné avec le consentement comme dans : prompt=select_account+consent

utilisation de l'autorisation via la bibliothèque client JS

Vous n'obtenez pas la sélection multi-utilisateurs. paramètre suivant : authuser=0 Cela sélectionne automatiquement le premier compte avec lequel vous êtes connecté (authuser=1 choisirait le deuxième, etc.). etc.).

---

4. Mise à jour : Avec le SSO désactivé, tout fonctionne bien... les sessions ne sont pas tuées...

SSO fédéré basé sur SAML

Voici comment configurer l'ouverture de session unique (SSO) via SAML pour l'application Slack®. .

Utilisation du langage SAML (Security Assertion Markup Language) leurs informations d'identification Google Cloud pour se connecter aux applications d'entreprise.

En tant qu'administrateur, vous devez configurer quelques éléments pour que cela fonctionne, notamment :

• Configurer l'application sélectionnée en tant que fournisseur de services SAML (SP).
• Configurez G Suite comme fournisseur d'identité SAML (IdP).
• Entrez les détails du fournisseur de services spécifiques à l'application dans la console d'administration Google.
• Activez l'authentification unique (SSO) pour l'application.
• Vérifiez que le SSO fonctionne.

Configurez les applications cloud pré-intégrées ou votre propre application SAML.

Se connecter . Cliquez sur Apps > SAML apps. Sélectionnez le site Ajouter un service/une application à votre domaine et la configuration :

Activez le SSO pour votre nouvelle application SAML. :

Connectez-vous à votre Console d'administration . G Apps > Apps SAML .

Sélectionnez l'application. En haut de la boîte grise, cliquez sur Plus de paramètres et choisir :

• On for everyone pour activer le service pour tous les utilisateurs (cliquez à nouveau pour confirmer).
• Off pour désactiver le service pour tous les utilisateurs (cliquez à nouveau pour confirmer).
• Activé pour certaines organisations afin de modifier le paramètre uniquement pour certains utilisateurs.

Utiliser Google Sign-In avec les applications informatiques

Voici une liste de contrôle des étapes Connectez-vous avec des comptes professionnels pour une application informatique développée sur mesure. Si vous développez une application mobile, reportez-vous aux b mobile également.

Si votre application connait le domaine Google for Work du compte, vous devez transmettre ce domaine au serveur d'authentification afin que seuls les comptes de ce domaine soient autorisés. domaine soient affichés lors de la connexion. [ ] setHostedDomain et, sur iOS, cela se fait avec la méthode de construction Domaine hébergé propriété.

Cela se fait également à l'aide de l'option hd p le paramètre hosted_domain avec l'API JavaScript.

---

5. Que ... à définir dans SAML XML que nous envoyons à l'URL ACS de Google.

Configuration des métadonnées du fournisseur pour l'intégration SAML

Les métadonnées SAML sont utilisées pour partager les données de configuration. fournisseur d'identité (IdP) et le fournisseur de service (SP). [ ] l'IdP et le SP sont définies dans un fichier XML :

Le fichier XML des métadonnées IdP contient les éléments suivants l'URL de redirection, et l'URL de post, f saml_idp_metadata.xml .

<?xml version="1.0" encoding="UTF-8"?>
  <md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" entityID="https://test.my.company.com" validUntil="2024-08-13T07:37:40.675Z">
    <md:IDPSSODescriptor WantAuthnRequestsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
      <md:KeyDescriptor use="signing">
        <ds:KeyInfo>
          <ds:X509Data>
            <ds:X509Certificate>encoded_certificate</ds:X509Certificate>
          </ds:X509Data>
        </ds:KeyInfo>
      </md:KeyDescriptor>
    <md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</md:NameIDFormat>
    <md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://https://test.my.company.com/idp/endpoint/HttpPost"/>
    <md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://test.my.company.com/idp/endpoint/HttpRedirect"/>
  </md:IDPSSODescriptor>
</md:EntityDescriptor>

Le fichier XML des métadonnées SP contient et l'URL du service de consommation d'assertions saml_sp_metadata.xml .

<EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" entityID="http://client.mydomain.com:80/webconsole">
  <SPSSODescriptor WantAssertionsSigned="true" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
    <AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="http://client.mydomain.com:80/webconsole/samlAcsCallback.do" isDefault="true"/>
    <KeyDescriptor>
      <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        <ds:X509Data>
          <ds:X509Certificate>encoded_certificate</ds:X509Certificate>
        </ds:X509Data>
      </ds:KeyInfo>
    </KeyDescriptor>
    <NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:entity</NameIDFormat>
  </SPSSODescriptor>
</EntityDescriptor>

Avant d'utiliser SAML pour se connecter à la console Web, rencontrez les personnes suivantes doivent être téléchargées et les métadonnées du SP doivent être générées. Après le métadonnées du PS sont générées, elles doivent être partagées avec l'IdP. Contactez le IdP pour obtenir des instructions sur le partage des métadonnées du SP.

Créer une métadonnée XM de fournisseur d'identité (IdP) à l'aide du protocole SAML. Pour connaître les spécifications des métadonnées SAML, consultez le site Web de la Commission européenne. O site web , M Security Assertion Markup Language (SAML) V2.0 .

Créez un fichier keystore. F C Intégration .

Pour plus d'informations sur l'utilitaire keytool, consultez le site Web de la Commission européenne. O Site de documentation , k et des certificats Tool .

URL des fournisseurs de services SAML

Pour configurer G Suite comme fournisseur d'identité SAML les URL des fournisseurs de services SAML pour chacun des services individuels applications en nuage préconfigurées que vous prévoyez de configurer.

Liens pour l'entité l'URL de l'ACS et l'URL de départ pour chacune des applications en nuage préconfigurées. préconfigurées.

---

6. Dépannage de l'ouverture de session unique (SSO)

Ce document fournit des étapes pour résoudre les erreurs m communes l'intégration ou l'utilisation de S (SSO) BASÉE SUR SAML w Google est le fournisseur de services (SP).