diff --git a/.nojekyll b/.nojekyll
new file mode 100644
index 0000000..e69de29
diff --git a/CNAME b/CNAME
new file mode 100644
index 0000000..636b108
--- /dev/null
+++ b/CNAME
@@ -0,0 +1 @@
+connect.canada.ca
diff --git a/CODE_OF_CONDUCT.md b/CODE_OF_CONDUCT.md
new file mode 100644
index 0000000..bc4db9d
--- /dev/null
+++ b/CODE_OF_CONDUCT.md
@@ -0,0 +1,122 @@
+# Contributor Covenant Code of Conduct for the Sign In Canada project
+
+([Français](#Code-de-conduite-pour-le-projet-authenti-canada))
+
+Contributors to repositories hosted in Sign In Canada are expected to follow the Contributor Covenant Code of Conduct, and those working within Government are also expected to follow the Values and Ethics Code for the Public Sector
+
+## Values and Ethics Code for the Public Sector
+
+The [Values and Ethics Code for the Public Sector](https://www.tbs-sct.gc.ca/pol/doc-eng.aspx?id=25049)
+
+## Our Pledge
+
+In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, religion, or sexual identity and orientation.
+
+## Our Standards
+
+Examples of behavior that contributes to creating a positive environment include:
+
+* Using welcoming and inclusive language
+* Being respectful of differing viewpoints and experiences
+* Gracefully accepting constructive criticism
+* Focusing on what is best for the department
+* Showing empathy towards other members
+
+Examples of unacceptable behavior by participants include:
+
+* The use of sexualized language or imagery and unwelcome sexual attention or advances
+* Trolling, insulting/derogatory comments, and personal or political attacks
+* Public or private harassment
+* Publishing others' private information, such as a physical or electronic address, without explicit permission
+* Other conduct which could reasonably be considered inappropriate in a professional setting
+
+## Our Responsibilities
+
+Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior.
+
+Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful.
+
+## Scope
+
+This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project, members or Treasury Board of Canada Secretariat (TBS).
+Examples of representing a project, members or TBS include using an official project e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event.
+Representation of a project may be further defined and clarified by project maintainers.
+
+## Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team at Signin-AuthentiCanada.ca.
+All complaints will be reviewed and investigated and will result in a response that is deemed necessary and appropriate to the circumstances.
+The project team is obligated to maintain confidentiality with regard to the reporter of an incident.
+Further details of specific enforcement policies may be posted separately.
+
+Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership.
+
+## Attribution [EN]
+
+This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4,
+available at [https://www.contributor-covenant.org/version/1/4/code-of-conduct.html](https://www.contributor-covenant.org/version/1/4/code-of-conduct.html)
+
+[homepage]: https://www.contributor-covenant.org
+
+This Code of Conduct is also inspired by GDS' `alphagov` [Code of conduct](https://github.com/alphagov/code-of-conduct)
+
+---
+
+# Code de conduite pour le projet Authenti-Canada
+
+
+([English](#Contributor-Covenant-Code-of-Conduct-for-the-sign-in-canada-project))
+
+Les contributeurs aux dépôts hébergés dans Authenti-Canada sont tenus de respecter le Code de conduite du Pacte des contributeurs, et ceux qui travaillent au sein du gouvernement sont également tenus de respecter le Code de valeurs et d'éthique du secteur public.
+
+## Notre engagement
+
+Dans le but de favoriser un environnement ouvert et accueillant, nous nous engageons, en tant que collaborateurs et responsables, à faire de la participation à notre projet et à notre communauté une expérience sans harcèlement pour tous, quels que soient leur âge, leur taille, leur handicap, leur origine ethnique, leurs caractéristiques sexuelles, leur identité et expression sexuelles, leur niveau d'expérience, leur éducation, leur statut socio-économique, leur nationalité, leur apparence, leur race, leur religion et leur orientation sexuelle et leur identité.
+
+## Nos normes
+
+Exemples de comportements qui contribuent à créer un environnement positif incluent :
+
+* Utiliser un langage accueillant et inclusif
+* Être respectueux des différents points de vue et expériences
+* Accepter gracieusement les critiques constructives
+* Se concentrer sur ce qui est le mieux pour la communauté
+* Faire preuve d'empathie envers les autres membres de la communauté
+
+Voici des exemples de comportements inacceptables de la part des participants :
+
+* L'utilisation d'un langage ou d'images sexualisés et d'une attention sexuelle importunée, ou percées
+* Trollage, commentaires insultants ou méprisants, et attaques personnelles ou politiques
+* Harcèlement public ou privé
+* La publication d'informations privées d'autrui, telles que des informations physiques ou électroniques. adresse, sans autorisation explicite
+* Tout autre comportement qui pourrait raisonnablement être considéré comme inapproprié dans le cadre d'une enquête du contexte professionnel
+
+## Nos responsabilités
+
+Les responsables de la mise à jour du projet ont la responsabilité de clarifier les normes d'acceptabilité du et on s'attend à ce qu'ils prennent des mesures correctives appropriées et équitables en cas de comportement inacceptable.
+
+Les responsables de projet ont le droit et la responsabilité de supprimer, d'éditer ou de rejeter les commentaires, les soumissions (commits), le code, les éditions du wiki, les problèmes et autres contributions qui ne sont pas conformes au présent Code de conduite, ou d'interdire temporairement ou définitivement tout contributeur pour d'autres comportements qu'ils jugent inappropriés, menaçant, offensant ou nuisible.
+
+## Portée
+
+Ce Code de conduite s'applique dans tous les espaces du projet, et il s'applique également lorsque une personne représente le projet ou sa communauté dans les espaces publics.
+Des exemples de représentation d'un projet ou d'une collectivité comprennent l'utilisation d'un représentant officiel de la l'adresse électronique du projet, l'affichage par l'entremise d'un compte officiel de médias sociaux ou le fait d'agir à titre intérimaire en tant que représentant désigné lors d'un événement en ligne ou hors ligne.
+La représentation d'un projet peut être mieux défini et clarifié par les responsables du projet.
+
+## Application des règles
+
+Les cas de comportement abusif, de harcèlement ou d'autres comportements inacceptables peuvent être rapportés en communiquant avec l'équipe de projet à l'adresse suivante : Signin-AuthentiCanada.ca.
+Toutes les plaintes feront l'objet d'un examen et d'une enquête et donneront lieu à une réponse qui est jugée nécessaire et appropriée dans les circonstances.
+L'équipe de projet est dans l'obligation de respecter la confidentialité à l'égard du déclarant d'un incident.
+De plus amples détails sur les politiques d'application spécifiques peuvent être affichés séparément.
+
+Les responsables de projet qui ne respectent pas ou n'appliquent pas le Code de conduite en bonne et due formepeuvent faire face à des répercussions temporaires ou permanentes déterminées par d'autres membres de la les membres de la direction du projet.
+
+## Attribution [FR]
+
+Le présent Code de conduite est adapté de la version 1.4 du [Pacte du contributeur][page d'accueil],
+disponible à l'adresse [https://www.contributor-covenant.org/version/1/4/code-of-conduct.html](https://www.contributor-covenant.org/version/1/4/code-of-conduct.html)
+
+[page d'accueil]: https://www.contributor-covenant.org
+
+Le présent Code de conduite s'inspire également du " Code de conduite " du [alphaGov](https://github.com/alphagov/code-of-conduct) de GDS.
diff --git a/LICENSE b/LICENSE
new file mode 100644
index 0000000..696c3d2
--- /dev/null
+++ b/LICENSE
@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) Her Majesty the Queen in Right of Canada, as represented by the Treasury Board of Canada Secretariat, 2022
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.
diff --git a/SECURITY.html b/SECURITY.html
new file mode 100644
index 0000000..27eb19c
--- /dev/null
+++ b/SECURITY.html
@@ -0,0 +1,14 @@
+
+
+
Do not post any security issues on the public repository! Security vulnerabilities must be reported by email to SignIn-AuthentiCanada@tbs-sct.gc.ca
+
+
+
+
Sécurité
+
+
Ne publiez aucun problème de sécurité sur le dépôt publique! Les vulnérabilités de sécurité doivent être signalées par courriel à SignIn-AuthentiCanada@tbs-sct.gc.ca
Impact of SSC MFAaaS 3.0 on Sign In Canada Clients
+
+
The External Credential Management (ECM) team at Shared Services Canada (SSC) rolled out Multifactor Authentication as a Service 3.0 (MFAaaS 3.0) for the Government of Canada Credential Federation (GCCF) consolidator service on July 31st, 2023.
+
+
As part of this rollout, all GCCF Relying Parties (RPs) were migrated to the MFAaaS 3.0 platform, unless they opted out of the platform by following a pre-defined process.
+
+
The Sign In Canada (SIC) service utilizes the SSC Multifactor Authentication as a Service 2.0 (MFAaaS 2.0) platform to provide Time-Based One-Time Password (TOTP) Multifactor Authentication (MFA) to SIC clients who have MFA enabled for their service(s).
+
+
As a result, Sign In Canada has opted out of the SSC MFAaaS 3.0 platform and will continue to utilize the MFAaaS 2.0 platform. Any RPs integrated with SIC using MFA will continue to use the existing MFA option. There will be no impact to, or action required by SIC clients.
+
+
If clients would like to leverage the MFAaaS 3.0 platform, they would need to move to the SSC GCCF consolidator. Please contact the SSC ECM mailbox or visit the ECM GCpedia page for additional information on the GGCF consolidator or MFAaaS 3.0 services.
+
+
The new Enterprise Customer Identity and Access Management (CIAM) Software as a Service (SaaS) solution being procured to replace SIC will provide additional MFA options in the future. If you would like to keep informed on the progress of the CIAM project, please reach out to the Sign In Canada mailbox.
+
+
July 31st, 2023
+
Sign In Canada maintenance phase
+
+
In order to ensure prioritization of an enterprise Customer Identity and Access Management (CIAM) Software as a Service (SaaS) solution, the Sign In Canada (SIC) service is entering a maintenance phase. As a result, there will be no new enhancements to or integrations with the SIC Minimum Viable Product (MVP).
+
+
The service will continue to operate with current support levels for existing integrations and clients. Any updates will be limited to bug fixes and security patches. This means that no new applications will be onboarded to the SIC MVP.
+
+
All prospective customers will need to leverage the Shared Services Canada (SSC) Government of Canada Credential Federation (GCCF) consolidator service until the enterprise CIAM solution is in place. The CIAM SaaS contract is targeted to be awarded in spring of 2024 with departmental specific solutions planned to be integrated afterwards.
+
+
Existing SIC clients will be migrated onto the new CIAM solution once it has been procured and deployed. Please rest assured that we will provide additional details on the status of the CIAM procurement along with migration plans when more specific information is available.
+
+
Please contact the SSC External Credential Management (ECM) mailbox (ecm-gje@ssc-spc.gc.ca) for additional information about the GCCF consolidator service.
+
+
If you have any questions or concerns, or would like additional information about the CIAM procurement, please don’t hesitate to reach out to the Sign In Canada mailbox.
When contributing, post comments and discuss changes you wish to make via Issues.
+
+
Feel free to propose changes by creating Pull Requests. If you don’t have write access, editing a file will create a Fork of this project for you to save your proposed changes to. Submitting a change to a file will write it to a new Branch in your Fork, so you can send a Pull Request.
+
+
If this is your first time contributing on GitHub, don’t worry! Let us know if you have any questions.
+
+
Security
+
+
Do not post any security issues on the public repository! See SECURITY.md
One of the primary goals of the Sign In Canada Platform is to facilitate the
+replacement of old credential service provider systems, in particular, the
+outsourced legacy GCKey and Credential Broker Service systems that have been in
+use since 2011.
+
+
One of the key prerequisites for decommissioning or replacing these old systems
+is to move the pairwise identifier mappings currently held by these older
+services to the Sign In Canada Platform, so that users’ enrolments with relying
+parties are not impacted when relying parties move to Sign In Canada.
+
+
The Sign In Canada Platform implements a feature that is able to
+automatically copy a user’s pairwise identifier mappings from a legacy
+credential service to the Sign In Canada Platform the first time they are used.
+These are then stored by the Sign In Canada Platform for future use, so that the
+mapping stored by the credential service is no longer required. This reduces the
+risk and effort required to move this data. Over time the mapping data of active
+users is gradually “collected” by the Sign In Canada Platform, reducing the need to
+regularly copy the data manually via some kind of “bulk transfer”.
+
+
How it works
+
+
+
+
The Sign In Canada Platform accomplishes the automatic collection of pairwise
+identifier mappings as part of the normal user login process, by sending a second
+SAML authentication request to the legacy credential service providers when
+required.
+
+
+
The process begins when a relying party sends an authentication request to
+the Sign In Canada Platform, using either OpenID Connect or SAML.
+
The Sign In Canada Platform then sends an authentication request to the CSP on
+its own behalf. Requesting the pairwise identifier that the CSP has created
+for Sign In Canada.
+
Upon receiving the SAML Assertion from the CSP, the Sign In Canada Platform looks
+the user up in its own user profile repository.
+
The Sign In Canada Platform then checks to see if it already has a pairwise
+identifier mapping for the authenticated user with the requesting relying
+party. If so, then collection is not required, the login flow completes
+normally, and the Sign In Canada Platform returns the appropriate pairwise
+identifier to the relying party (RP).
+
If however, the Sign In Canada Platform does not have a pairwise identifier
+mapping for the authenticated user with the requesting relying party, then it
+sends a second authentication request to the CSP on the relying party’s
+behalf.
+
If the CSP has an existing pairwise identifier for the user with the
+requesting RP, it returns that identifier in an Assertion and the Acceptance
+platform adds it to its own user repository. At this point, the identifier
+has been “collected” by the Sign In Canada Platform, and will be used whenever
+the user logs into that RP in the future (as per step 4 above).
+
If the CSP does not have an existing pairwise identifier for the user with
+the requesting RP then there is nothing to “collect”, so the Acceptance
+Platform creates a new identifier for the user with the requesting RP, and
+that identifier is used for all future logins.
+
+
+
Technical Details
+
+
When sending a second authentication request to the CSP on behalf or the relying
+party, the Sign In Canada Platform makes use of the <NameIDPolicy> element of the
+SAML <AuthnRequest> message. Specifically, it uses the following two
+attributes of the <NameIDPolicy> element:
+
+
+
The value of the SPNameQualifier attribute is populated with the old SAML
+Entity Id of the requesting relying party, to indicate that the Acceptance
+Platform is requesting the RP’s pairwise identifier instead of its own.
+
The value of the AllowCreate attribute is set to "false", to indicate to
+the CSP that it should not create a new pairwise identifier for the RP if is
+does not already have one.
+
+
+
Here is an example of an authentication request issued by the Acceptance
+Platform on behalf of itself:
What does the user experience? Do they need to enter their password twice?
+
+
This process takes advantage of the Single Sign On features inherent in SAML, so
+that the user will not have to authenticate more than once, if at all:
+
+
+
If the user is not already logged in to the CSP, or if they are logged in
+but the single sign-on (SSO) window (20 minutes with the GCCF CSPs) has
+expired, they will be prompted to authenticate after the first SAML
+authentication request. After they successfully log in to the CSP, the the
+Sign In Canada Platform then sends the second authentication request a fraction of
+a second later, well within the SSO window, so they will not be prompted to
+login a second time.
+
In the unlikely case where the user is already logged in to the CSP, but the
+SSO window expires within the fraction of a second between the two
+authentication requests, then SSO will apply to the first request, but not to
+the second. Again, the user only needs to provide their credentials once.
+
If the user is already logged in to the CSP, and both authentication requests
+are processed within the SSO window, then the CSP will not prompt the user to
+re-enter their credentials at all. The relying party can override this
+behaviour by specifying prompt="login" (for OpenID Connect) or
+forceAuthn="true" (in SAML) in their authentication request to Sign In
+Canada, in which case the Sign In Canada Platform will specify
+forceAuthn="true" on it’s first request to the CSP, but not the second.
+
+
+
What if the user at the keyboard changes? Is there a risk that the Sign In Canada Platform could collect the wrong identifier belonging to the wrong person?
+
+
This possible scenario can arise in cases where multiple people are sharing the
+same device, and one of them has left the device unattended while they were
+still logged in to the CSP. For example:
+
+
Consider two users, Alice and Bob, who both have access to the same shared computer:
+
+
+
Alice logs into a GCCF relying party using her GCKey, but then walks away from
+ the computer without logging off.
+
Bob then sits down at the same computer and attempts to log in to a Sign In
+ Canada relying party, just a few seconds before Alice’s 20 minute single-sign
+ on window expires.
+
The Sign In Canada Platform sends the first authentication request to GCKey, and
+ receives Alice’s pairwise identifier in return.
+
Alice’s SSO window then expires in the fraction of a second before the
+ Sign In Canada Platform sends the second authentication request. GCKey prompts Bob
+ to enter his GCKey credentials and then returns Bob’s pairwise identifier to
+ the Sign In Canada Platform.
+
The Sign In Canada Platform then associates Bob’s GCKey identifier with Alice’s
+ user profile.
+
+
+
In order to safeguard against this, the Sign In Canada Platform checks the
+SessionIndex of both SAML Assertions, and makes sure that they match before
+accepting the collected identifier.
+
+
SAML Pairwise identifiers issued by an identity provider (IDP) are supposed to be specific to a SAML service provider (SP). How is Sign In Canada allowed to obtain the identifiers generated for another SAML SP?
+
+
The SAML specifications allow for the existence of Affiliations: groups of one
+or more SPs that share the same pairwise identifier for a given user. When a
+relying party moves from the GCCF to Sign In Canada, a new SAML Affiliation is
+defined, via SAML metadata, that allows the Sign In Canada Platform to obtain
+the pairwise identifiers that were originally created for the RP.
The Sign In Canada client acceptance test environment is available to anyone in
+the GC who wishes to:
+
+
+
Learn how to use OpenID Connect to integrate with Sign In Canada
+
Develop and test new digital service delivery applications
+
+
+
Integrating a sandbox, development, or test environment to Sign In Canada is fast, and
+easy. Simply send an email to Signin-AuthentiCanada@tbs-sct.gc.ca with some
+basic information about your application such as the cloud service or
+development platform are you using. The Sign In Canada team will help you get
+your application connected and working, often within one or two days.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/en/discover/images/CSP-initiated-logout.svg b/en/discover/images/CSP-initiated-logout.svg
new file mode 100644
index 0000000..053f75f
--- /dev/null
+++ b/en/discover/images/CSP-initiated-logout.svg
@@ -0,0 +1,846 @@
+
+
+
+
diff --git a/en/discover/images/Overview.svg b/en/discover/images/Overview.svg
new file mode 100644
index 0000000..9276faa
--- /dev/null
+++ b/en/discover/images/Overview.svg
@@ -0,0 +1,1582 @@
+
+
+
diff --git a/en/discover/images/SP-initiated-logout.svg b/en/discover/images/SP-initiated-logout.svg
new file mode 100644
index 0000000..0b98458
--- /dev/null
+++ b/en/discover/images/SP-initiated-logout.svg
@@ -0,0 +1,914 @@
+
+
+
+
diff --git a/en/discover/images/sic-overview.png b/en/discover/images/sic-overview.png
new file mode 100644
index 0000000..aeca11a
Binary files /dev/null and b/en/discover/images/sic-overview.png differ
diff --git a/en/discover/index.html b/en/discover/index.html
new file mode 100644
index 0000000..3d5ef70
--- /dev/null
+++ b/en/discover/index.html
@@ -0,0 +1,206 @@
+
+
+
+
+
+
+
+ What is the Sign In Canada (SIC) Platform?
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
The Sign In Canada platform provides an umbrella service that acts as a trusted intermediary between
+providers of credential services, and government programs who consume them to provide services to their
+external clients (e.g., individuals, businesses, and representatives).
Applications integrate with the Sign In Canada platform using the industry standard OpenID Connect protocol. OpenID Connect is widely supported by most major:
+
+
+
Software-as-a-Service and Platform-as-a-Service cloud products, including
+
The Sign In Canada production environment has been live since March 2021.
+
+
Security Authorization
+
+
The security of the Sign In Canada production environment has been assessed and authorized to authenticate users on behalf of relying party applications:
for which the sensitivity (confidentiality, integrity, and availability) of any data to be processed, stored, transmitted on or by the Relying Parties does not exceed Protected B, Medium Integrity, Medium Availability (PM/M/M).
+
+
+
Availability
+
+
The production environment operates 24 hours a day, 365 days a year, with a target availability of 99.8% calculated monthly and inclusive of scheduled maintenance activities.
+
+
Performance
+
+
The performance of the production environment is calculated by measuring the response time for every HTTP request received by the service. These HTTP requests include all those received from users’ browsers for web pages and related web content, and all requests to the Sign In Canada application programming interfaces (APIs) from relying party applications.
+
+
The performance target for the production environment is to respond to 95% of HTTP requests within 200 milliseconds or less, and to respond to 99 % of HTTP requests within 500 milliseconds or less.
+
+
Capacity
+
+
The production environment currently has sufficient capacity to authenticate up to 12 users per second (43,200 per hour).
+
+
Data Backup and Recovery
+
+
All user data and all relying party configuration data stored in the production environment is backed up once per hour, every hour to geographically redundant storage, with a durability of at least 99.99999999999999% over a given year.
+
+
Monitoring
+
+
The availability and performance of the production environment is monitored 24 hours a day, 365 days a year. This monitoring is fully automated.
+Whenever an availability interruption or performance degradation is detected, members of the Sign In Canada support team are automatically alerted by email and by text message.
The speed at which the Sign In Canada support team responds to production
+service incidents depends on when the incident is detected or reported (all
+times listed are eastern time):
+
+
+
+
+
Incident Occurrence Window
+
Response Target
+
+
+
+
+
Working days, 8am to 5pm
+
Immediate
+
+
+
Working days, 5pm to 10pm
+
Best Effort
+
+
+
Weekends and Holidays, 8am to 10pm
+
Best Effort
+
+
+
Nights, 10pm to 8am
+
Next day, as per above
+
+
+
+
+
Planned Maintenance
+
+
Software Maintenance
+
+
The Sign in Canada software requires regularly scheduled maintenance to meet the
+established service levels and to introduce new features. To minimize the effect
+on relying parties, maintenance activities that require taking the service
+off-line are normally scheduled during a defined software maintenance window,
+from 4am to 5am eastern time on Sunday mornings. Relying parties are not
+normally notified of planned outages that take place during this window, which
+are normally 10 to 25 minutes in duration. In exceptional cases, where a
+maintenance outage needs to be scheduled outside of this window, the Sign In
+Canada team will provide relying parties with at least 7 days notice.
+
+
Network Maintenance
+
+
The Sign in Canada production environment leverages network security
+infrastructure that is managed by the TBS Enterprise Architecture and
+Infrastructure team. This infrastructure also requires periodic maintenance,
+which is normally scheduled for the Thursday following the 2nd Tuesday of the
+month, from 8pm to midnight. Planned network infrastructure maintenance does not
+always affect service availability, but in cases where an outage is possible the
+Sign In Canada team will make every effort to inform relying parties in advance.
+
+
Unscheduled maintenance
+
+
The Sign In Canada production environment leverages cloud, platform and
+infrastructure support from both TBS and SSC. They reserve the right to schedule
+emergency maintenance outages for critical updates, with the goal of providing
+relying parties at least twenty-four (24) hours advance notice. Both parties
+will work on a best-efforts basis, to schedule these outages during non-peak
+hours and limit their occurrence to strictly necessary upgrades and required
+maintenance. (It should be noted that this is for emergency maintenance and not
+emergency fixes following an incident).
+
+
Service dependencies
+
+
The Sign In Canada service leverages three credential services provided by
+Shared Services Canada, namely the Government of Canada-branded credential
+service “GCKey”, the credential broker service “Government Sign-In by
+Verified.Me”, and the 2nd-factor authentication service. The service levels for
+these three services are separate and distinct from those of the Sign In Canada
+production environment.
+
+
Relying Party Support
+
+
Relying parties can report incidents or request troubleshooting assistance by
+sending an email to SignIn-AuthentiCanada@tbs-sct.gc.ca. The Sign In Canada
+support team monitors this mailbox from 8am to 5pm on working days.
The Sign in Canada Platform functions as a session management authority that
+centrally coordinates users’ sessions across multiple Relying Party (RP)
+applications. There are two key features of the platform that support this:
+single sign-on, and single logout.
+
+
Single Sign-On
+
+
Once a user has successfully used a given credential or trusted digital identity
+service to authenticate to one RP, Sign In Canada can allow them to silently
+authenticate to other RPs subject to a single sign-on timeout period. The
+platform accomplishes this by creating its own session with the user when they
+first sign in, and then simply not prompting them to re-authenticate when they
+sign in to other RPs within a specified timeout window.
+
+
The timeout window for single sign-on starts whenever a user enters their
+correct password at a credential service provider (CSP), and ends after a
+specified period of time has elapsed. By default this is 20 minutes, but Sign
+In Canada relying parties can change this if desired. It is important to note
+however that the single sign-on window of the legacy GCKey and Credential Broker
+services, which is also 20 minutes, cannot be changed, it can only be disabled
+(called forced authentication). In any situation where the “hard-coded” legacy
+timeout might come into conflict with a relying party’s preferred timeout, the
+Sign In Canada platform will automatically synchronize the two, and resolve the
+conflict.
+
+
Note that in order for single sign-on to work, a user must use the same
+credential or trusted digital identity to access all digital government
+services. At present, this not possible since not all Government of Canada
+services accept the same credentials. For example, accessing online tax services
+provided by CRA is currently not possible using a CKey credential, therefore
+users who chose to use a GCKey credential cannot single sign-on to CRA’s My
+Account for
+Individuals.
+
+
Single Logout
+
+
When a user has visited multiple web sites (Relying Party applications) during
+the same session, the Sign In Canada Platform has the ability to centrally
+coordinate single logout. With single logout, the user only has to click one
+logout button on the site they are currently visiting, and Sign In Canada will
+then log them out of all the other sites they have visited during their session.
Both the OpenID Connect (OIDC) and SAML protocols follow the same basic sequence
+of events:
+
+
+
As a user visits multiple web sites (applications) within the same session,
+the Sign In Canada Platform keeps track of which sites they have visited.
+
When the user clicks a logout button on one of the the sites they are
+visiting, that site’s web application sends a logout request to the
+Sign In Canada Platform.
+
Sign In Canada then sends a logout request to all of the other sites
+the user has visited, so they can log the user out.
+
+
+
Transition and Coexistence
+
+
There will be an extended transition period as RP applications connect to Sign
+In Canada and disconnect from the legacy Government of Canada Credential
+Federation (GCCF) GCKey and Credential Broker services one at a time. During
+this transition period, the Sign In Canada Platform will serve as the session
+management authority for applications connected to it, while the GCKey and
+Credential Broker services serve as the session management authority for
+applications connected to them.
+
+
This creates a requirement for Sign In Canada to coordinate single logout with
+GCKey and CBS, as well as with its own RPs. The platform accomplishes this by
+supporting the SAML Single Logout profile as part of its integration, as a SAML
+proxying identity provider, with GCKey and CBS. The Sign In Canada platform is
+able to coordinate single logout with the legacy GCCF in both directions. That
+is, regardless of whether the user logs out of Sign In Canada first or whether they
+log out of the GCCF first.
+
+
Scenario 1: A user logs out of Sign In Canada first
+
+
The following example scenario illustrates how single logout is achieved in the
+case where the user clicks a logout button on a relying party site that is connected to
+Sign In Canada.
+
+
+
+
The scenario begins when a user clicks a logout button on the relying party site
+they have been using. When this happens:
+
+
+
The relying party application logs the user out locally first, then it
+redirects the browser to either the Acceptance Platforms’s OpenID Connect end_session endpoint.
+
If any relying parties participating in the session support OpenID Connect
+back-channel logout, the Acceptance Platform first sends a logout token to
+all of them, via an HTTP POST to their registered back-channel logout URI(s)
+to trigger the logout actions by those RPs. If there are multiple relying
+parties then these requests are all sent simultaneously, in parallel.
+
Once back-channel logout has been completed, The Acceptance Platform then
+returns an HTML logout propagation
+page to the browser. This page contains a number of
+iframe
+elements. The src (source) attribute of all but one of the iframe
+elements points to the front-channel logout
+URI
+of one of the Sign In Canada relying party sites where the user has logged in
+during their current session. In the diagram, these other sites are
+identified as “Other OIDC RPs”. The src attribute of the final iframe
+points to a URI endpoint of the Acceptance Platform’s Acceptance Framework.
+
Upon receiving the propagation page, the browser begins to load all of the of
+the iframe_s in parallel, by asynchronously sending an HTTP GET request to
+the src URI of each _iframe.
+
As the other relying parties receive these requests, they log the user out
+locally, and then return an HTTP response to the browser.
+
When the Acceptance Platform’s Acceptance Framework receives its request, it
+creates a SAML LogoutRequest message and then redirects the browser with
+that message (within the iframe) to the legacy CSP (GCKey or CBS) that the
+user chose to log in with.
+
The legacy CSP then logs the user out of their credential. If the user has visited
+any sites that are still connected directly to the CSP (instead of to Sign in
+Canada) it will also propagate the logout to all of those sites, one at a time.
+
The CSP then redirects the browser (within the iframe) back to the
+Acceptance Platform’s Acceptance Framework with a SAML
+LogoutResponse message. The Acceptance Framework processes this
+message and then sends an HTTP response back to the browser.
+
The logout propagation page has a global onerror event handler that will be
+triggered if any kind of error occurs while all of the _iframe_s are
+propagating the logout to various sites asynchronously.
+
If any of the iframes fail or time-out, of if the SAML logout response
+ from the legacy CSP indicates an error, then the onerrorevent handler will
+ redirect the browser to an error
+ page,
+ warning the user that they may not be completely signed out and recommending
+ that they close their browser.
+
If all of the iframes successfully propagate logout to their target site,
+then the browser is redirected to the logout landing page of the site where
+the user initially clicked “Logout” (the relying party’s
+post_logout_redirect_uri).
+
+
+
Scenario 2: A user logs out of the GCCF first
+
+
The next example scenario illustrates how single logout is achieved in the case
+where the user clicks a logout button on a relying party site that is still
+connected one of the legacy GCCF credential services (GCKey or CBS).
+
+
+
+
The scenario begins when a user clicks a logout button on the relying party site
+they have been using. When this happens:
+
+
+
The relying party application logs the user out locally first, then it
+redirects the browser to the legacy CSP’s SAML Single Logout endpoint with a
+SAML LogoutRequest message.
+
If the user has visited additional sites that are still connected directly to
+the CSP (instead of to Sign In Canada) it will first propagate the logout to
+all of those sites using SAML back-channel (SOAP) logout. This is done one at
+a time, while the user waits, after which the user is now completely logged
+out of the GCCF.
+
To log the user out of Sign In Canada, the GCCF CSP then redirects the
+browser to Sign In Canada’s Acceptance Framework with a SAML LogoutRequest
+message.
+
The Acceptance framework then creates an OpenID Connect logout request and
+redirects the browser to the Acceptance Platform’s OpenID Provider (OP)’s
+end_session endpoint.
+
If any relying parties participating in the Acceptance Platform’s session
+support back-channel logout, the Acceptance Platform sends a logout token to
+all of them first, via an HTTP POST to their registered back-channel logout
+URI(s). This triggers the logout actions by each of those RPs. If there are
+multiple relying parties then these requests are all sent simultaneously, in
+parallel.
+
Once back-channel logout has been completed, the Acceptance Platform returns
+an HTML logout
+propagation page. This page contains a number of
+iframe
+elements. The src (source) attribute of each iframe element points to the
+front-channel logout
+URI
+of one of the relying party sites where the user has logged in during their
+current session. In the diagram, these other sites are identified as “Other
+SIC RPs”. The src attribute of the final iframe points to a URI endpoint
+of the Acceptance Platform’s Acceptance Framework.
+
Upon receiving the propagation page, the browser begins to load all of the of
+the iframe_s in parallel, by asynchronously sending an HTTP GET request to
+the src URI of each _iframe.
+
As the other relying parties receive these requests, they log the user out
+locally, and then return an HTTP response to the browser.
+
The logout propagation page has a global onerror event handler that will be
+triggered if any kind of error occurs while all of the _iframe_s are
+propagating the logout to various sites asynchronously.
+
If any of the iframes fail or time-out, the onerrorevent handler will
+ redirect the browser to the Acceptance Framework with an HTTP request that
+ indicates a logout problem.
+
+
The Acceptance Framework will then redirect the browser back
+to the CSP with a SAML LogoutResponse message bearing a status code of
+urn:oasis:names:tc:SAML:2.0:status:Responder.
+
The CSP will then in turn redirect the browser back to it’s own RP with a
+ LogoutResponse message bearing a top level status code of
+ urn:oasis:names:tc:SAML:2.0:status:Success and a second-level status
+ code of urn:oasis:names:tc:SAML:2.0:status:PartialLogout.
+
This will cause the SAML RP to display error page, warning the user that
+they may not be completely signed out and recommending that they close
+their browser.
+
+
+
If all of the iframes successfully propagate logout to their target site,
+the JavaScript code will redirect the browser to the Acceptance Framework
+with an HTTP request that indicates a successful logout.
+
+
The Acceptance Framework will then redirect the browser back to the CSP
+with a SAML LogoutResponse message bearing a status code of
+urn:oasis:names:tc:SAML:2.0:status:Success.
+
The CSP will then in turn redirect the browser back to it’s own RP with a
+LogoutResponse message bearing a top level status code of
+urn:oasis:names:tc:SAML:2.0:status:Success and no second-level status
+code.
+
This will cause the SAML RP to display their usual logout or landing page.
Gluu Passport is a Node.JS web application based
+on the Express web application framework and the
+Passport.JS authentication middleware.
+
+
As the name implies, This is the “Acceptance” component of the Acceptance
+Platform. It integrates with credential providers and trusted identity providers
+to accept assurances of credential and identity on behalf of GC relying
+parties.
+
+
Sign in Canada uses a version of Gluu Passport that has been customized to
+support some unique functionality that supports the coexistence with, and
+transition from, the older GCCF credential services, in particular:
+
+
+
It has been customized to support both the preservation and run-time migration
+of user’s existing PAIs from the Credential Service Provider (CSP) to the Acceptance Platform, so that the
+transition has no impact on end users’ enrolment with existing relying parties.
+
It has customized to support session coordination between the Acceptance
+Platform and the CSPs.
oxAuth is an open source OpenID Connect Provider
+(OP) and UMA
+Authorization Server (AS).
+
+
oxAuth is the core component of the Acceptance Platform, responsible for the
+user interface and business logic. As an OpenID
+Connect Provider, it also provides the application
+programming interface used by GC relying parties that integrate using OpenID
+Connect.
Shibboleth is a SAML Identity
+Provider (IDP) that provides the application programming interface used by GC
+relying parties that integrate using SAML.
Couchbase Server is an open-source, distributed, multi-model NoSQL
+document-oriented database software package that is optimized for interactive
+applications.
+
+
The Sign In Canada platform uses Couchbase to store user profiles and relying
+party configurations, as well as for high-performance distributed session
+caching.
Government of Canada digital services that leverage Azure Active Directory
+B2C to
+centrally manage user identity data, and/or to authorize access to their
+application programming interfaces can configure their B2C tenant to use
+Sign In Canada as its authentication service. This allows your users to benefit from
+being able to use the same trusted credential to access multiple government services,
+while your applications benefit from all of the features provided by Azure Active
+Directory B2C.
+
+
Requesting Connectivity to CATE for your B2C tenant
The Sign in Canada team will use this information to configure your B2C tenant
+as a client, and provide you with a client ID and client secret for your tenant.
+
+
+
+You must have a valid myKey credential so that the Sign in Canada team can send you these client credentials via encrypted email.
+
+
+
+
Configuring Sign In Canada as an Identity Provider
+
+
To configure the Sign In Canada CATE environment as your B2C tenant’s external
+identity provider you can follow these instructions
+and use the following settings:
This forces Sign In Canada to rely on its session cookie, however that session
+cookie will be blocked by most browsers as a third party cookie if the the B2C
+tenant is hosted under a different top-level domain than Sign In Canada.
+
+
Workaround
+
+
The B2C tenant must be configured to use a custom domain that is in the same
+top-level domain as the external IDP. In the case of Sign In Canada production
+environment, that top level domain is canada.ca, so any production B2C tenant
+must use a custom domain that is a subdomain under canada.ca.
+
+
Issue 2: B2C does not provide a an OpenID logout endpoint that accepts single logout requests coming from an external OpenID provider
+
+
Workaround
+
+
To log out the B2C session, The Sign In Canada platform can use the
+front-channel logout endpoint that B2C provides to its own clients. The B2C
+policy/user flow must be configured to not require the id_token_hint, since the
+Sign In Canada platform has no way to obtain a B2C client’s ID token.
+
+
To log out the session at B2C’s clients, the Sign In Canada platform can send
+each of them a logout request directly.
+
+
Issue 3: B2C’s logout endpoint sets an X-Frame-Options header to “deny” which blocks logout requests from Sign In Canada
+
+
Workaround
+
+
A “Modify Response Header” rule can be configured on Azure Front Door to remove
+the offending header.
Whether you are working with a cloud-based service or developing your own
+application, you can integrate your non-production environment(s) to the Sign In
+Canada Client Acceptance Test Environment: Find out how.
If you cannot sign in to your bank, please contact them for support.
+
+
Two step verification
+
+
+
+Why am I being asked to set up a ‘second step’?
+
+
Two step verification is an extra layer of security that requires a code in addition to your password to access your account. This code can be sent to your phone or generated by the authenticator app.
+
+
Think of it like a locked door that can only be opened with both a key and a secret code. Someone pretending to be you on the internet should never be able to get both the key and the code.
+
+
+
+
+What do you do with my information?
+
+
Your phone number will be used to:
+
+
Send you codes to help verify it’s you signing in each time
+
Notify you of any changes made to your sign in settings.
An authenticator app is a tool that helps keep your online account safe. Every time you sign in, the app will give you a new code you will need to enter to prove it's you signing in. This is more secure than using your mobile phone number to receive a one-time code.
+
+
You can download or use a third-party app of your choice. You only need to download it to one device.
+
+
+
+
+What if I don’t have a second phone number?
+
+
If you don't have a second phone number, we recommend choosing the authenticator app as your two step verification method instead. This method only requires one smartphone device and an authenticator app of your choice.
+
+
Alternatively, if you have already chosen SMS and verified your phone number, you can choose to skip adding a second, backup phone number but if you lose access to your default phone you will be permanently locked out of the service you are signing in to. You will have to create a new account.
+
+
+
+
+What if I lose my phone or phone number?
+
+
If you set up a phone number as your two-step verification and have added a second, backup phone number, you can:
+
+
+
Select the ‘Try another method’ link on the screen you would have received your code
+
Select your backup phone number to send another code
+
Enter the code sent to your other phone
+
Sign in
+
+
If you set up a phone number as your two step verification and did not add a second, backup phone number and you have lost access to your phone number, unfortunately there is no way to recover your account. You will have to create a new account.
+
+
+
+
+How do I update a registered phone number?
+
+
If you need to make a change to a phone number you have registered you will have to add the new phone number and delete the one that is no longer needed:
+
+
+
Sign in as you normally would with your username, password and two step verification step
+
When you arrive on the You have successfully signed in screen, select the button Sign in settings
+
+
When you arrive on the Sign in settings screen, select the Add a mobile phone number option and follow the steps to add your new or updated phone number
+
+
+
To delete the old phone number:
+
+
+
From the main Sign in settings screen, select the Edit option next to the phone number you want to remove
+
On the Edit phone number screen, select the Delete option
+
For security, you will need to enter the full phone number to confirm the deletion
+ The Sign In Canada platform provides an umbrella service that acts as a trusted intermediary between
+ providers of credential services, and government programs who consume them to provide services to their
+ external clients (e.g., individuals, businesses, and representatives).
+
Ready to use the Sign In Canada Platform for your public-facing online service? Here’s what to expect:
+
+
Initial Engagement
+
+
This will be a series of meetings at the appropriate levels to provide an overview of the Sign In Canada service platform and supported credential services, and to discuss the objectives/scope of the client’s integration and high-level timelines.
+
+
Review and Agreement
+
+
Meetings/discussions will be held to further define:
+
+
+
Scope
+
Timeline and milestones
+
Costs
+
Success criteria
+
Problem/issue resolution
+
Availability of resources
+
+
+
Upon approval to proceed, a formal Collaboration Agreement document is signed.
+
+
Technical Discussion(s)
+
+
This will be a meeting held between the Sign In Canada onboarding team and
+client technical resources. The primary goal of these discussions is to
+establish points of contact, the integration approach and support expectations.
+
+
Client Acceptance Test Environment (CATE) Technical Configuration
+
+
The standard technical integration process is followed for all of the client’s
+non-production environments. Configuration requests are managed by the
+onboarding team with client support as required.
+
+
End-User Support Processes
+
+
The Sign In Canada team will facilitate meetings with Shared Service Canada to
+integrate the client’s end-user support processes with those of the applicable
+credential services (GCKey, CBS, 2nd factor).
+
+
User Migration
+
+
If required, the Sign In Canada team will work with Shared Service Canada to
+facilitate a seamless migration of the client’s existing GCKey and CBS users
+to the Sign In Canada platform.
+
+
Testing / Demonstration
+
+
To be completed by client with assistance from Sign In Canada team. Sign In
+Canada will provide support (when possible) for all demonstrations involving
+external or executive audiences.
+
+
Production
+
+
The Sign In Canada Team and the Client will collaborate to promote
+the solution to production.
+
+
Production Technical Configuration
+
+
The standard technical integration process will be followed. Configuration
+requests will be managed by the onboarding team with client support as required.
+
+
Go Live Activities
+
+
To be completed by the client with assistance from the Sign In Canada team.
+The client completes a Sign In Canada Federation Compliance Attestation (SFCA)
+form to certify appropriate security and privacy assessments have been completed,
+identified risks have been addressed, and the application obtained the
+appropriate Authority to Operate (ATO).
+
+
Production Integration Closing
+
+
Success criteria met – reporting on outcomes and closing Production Integration activities.
The TBS Infrastructure team will be performing network maintenance which may result in Sign In Canada service instability and an inconsistent user experience for a period of 10 minutes during this timeframe.
Sign in Canada is an online service that provides a secure and easy way to access multiple government programs and services. With the help of a credential like GCkey or a bank partner, Sign in Canada’s Multi-Factor Authentication (SIC MFA) service lets you securely sign into government agencies’ services.
+
+
The service is designed to make it easier and more secure for you to manage federal benefits, services, and applications. Sign in Canada works with other federal agencies (called “relying parties”) to give you access to their services.
+
+
Sign in Canada takes security seriously and uses strong measures to protect your account. The service also respects your privacy by collecting only the necessary information from you and sharing it only with the relying parties that need it to give you access to their service.
+
+
We collect your personal information
+
+
Your personal information includes your phone number. Information is collected only for the purpose of issuing and managing access to Government of Canada systems and applications and provide you with necessary communications. If you do not wish to use a phone number to access electronic services, you may apply for the service by phone, fax, mail, or in person.
+
+
For further details, refer to the corresponding relying party’s service contact information.
+
+
The personal information collected and used for signing up into a service is stored in Personal Information Bank PCU 607. This personal information will be retained for at least two years.
+
+
We use web analytics
+
+
We use analytics software to collect and store information about your visit to our site. This information includes:
+
+
+
Environmental information such as the location of your IP address, the language you are browsing in, and the technical specifications of the device and browser you are using;
+
Behavioural information such as the date and time of your visit, the pages you visit, links you clicked on the site, and the name of the domain from which you access the Internet
+
Acquisition information such as the Internet address of the website you came from if it linked you directly the SIC MFA service
+
If your browser accepts cookies, we may use a session cookie to learn how many different visitors come to Sign in Canada
+
+
+
This data is used to:
+
+
+
help us make our site more useful using statistics to assess what services are of most and least interest to our clients and determine technical design specifications;
+
identify system performance or problem areas;
+
protect the security of our website, identify unauthorized attempts to upload or change information, or to otherwise cause damage;
+
identify and resolve any problems or difficulties you encounter in attempting to sign into our sites.
+
+
+
We share some information
+
+
In the event of suspected security or privacy breaches, personal information may be shared with departmental security and access to information and privacy officials, as well as the federal government department or agency which collects and uses the personal information considered to have been compromised. The information may be shared with law enforcement authorities if we suspect criminal activities or other services that perform electronic network monitoring. This information is used for no other purposes and is scheduled for regular destruction in accordance with the Library and Archives of Canada Act and the Privacy Act.
+
+
We do not:
+
+
Authorize other services to use your information for anything unrelated to Sign in Canada
+
Sell or rent your personal information.
+
Share your personal information for marketing purposes.
The law requires that we protect your privacy. You have the right to access and review your personal information. Use your SIC MFA service to check, correct, or update your information.
+
+
If you have any questions, concerns and complaints regarding this notice, or the administration of the Privacy Act in connection with your SIC MFA service please contact the Access to Information and Privacy Protection Division by email at atip-aiprp@ssc-spc.gc.ca or by writing to the following address:
+
+Director, Access to Information and Privacy
+
+
Shared Services Canada
+
+
PO Box 9808, STN T, CSC
+
+
Ottawa ON K1G 4A8
+
+You also have the right to raise concerns about how we handle your personal information. To learn more or to make a formal complaint, contact the Privacy Commissioner of Canada.
+
+
Each relying party also has their own Privacy Policy. For more information, please refer to the corresponding Terms and Conditions and Privacy Notices on each relying party’s web page.
Ouverture de session à l’aide d’un partenaire financier
+
+
Si vous ne parvenez pas à ouvrir une session à votre banque, veuillez communiquer avec elle pour obtenir de l’aide.
+
+
Vérification en deux étapes
+
+
+
+Pourquoi me demande-t-on de mettre en place une « deuxième étape »?
+
+
La vérification en deux étapes est une couche de sécurité supplémentaire qui exige un code en plus de votre mot de passe pour accéder à votre compte. Ce code peut être envoyé à votre téléphone ou être généré par l’application d’authentification.
+
+
Imaginez que c’est une porte verrouillée et qu’il faut une clef et un code secret pour l’ouvrir. Quelqu'un qui se fait passer pour vous sur l'internet ne devrait jamais être en mesure d'obtenir à la fois la clé et le code.
+
+
+
+
+Que faites-vous avec mes renseignements?
+
+
Votre numéro de téléphone sera utilisé pour :
+
+
Vous envoyer des codes afin de vérifier votre identité à chaque ouverture de session
+
Vous aviser des changements apportés à vos paramètres de connexion
+
+
+
Votre numéro de téléphone sera stocké de façon sécuritaire.
Une application d’authentification est un outil qui permet de protéger votre compte en ligne. Chaque fois que vous ouvrez une session, l’application vous donne un nouveau code que vous devez saisir pour prouver que c’est bien vous qui ouvrez une session. Cette méthode est plus sécuritaire qu’utiliser votre numéro de téléphone mobile pour recevoir un code unique.
+
+
Vous pouvez télécharger ou utiliser une application de tiers de votre choix. Vous n’avez qu’à la télécharger sur un seul appareil.
+
+
+
+
+Que faire si je n’ai pas de deuxième numéro de téléphone?
+
+
Si vous n’avez pas de deuxième numéro de téléphone, nous vous recommandons de choisir l’application d’authentification comme méthode de vérification en deux étapes. Cette méthode ne nécessite qu’un seul téléphone intelligent et une application d’authentification de votre choix.
+
+
Par ailleurs, si vous avez déjà choisi la messagerie et vérifié votre numéro de téléphone, vous pouvez choisir de sauter l’ajout d’un numéro de téléphone de secours; toutefois, si vous n’avez plus accès à votre téléphone par défaut, vous ne pourrez plus accéder au service auquel vous vous connectez. Vous devrez alors créer un nouveau compte.
+
+
+
+
+Que se passe-t-il si je perds mon téléphone ou mon numéro de téléphone?
+
+
Si vous choisissez un numéro de téléphone pour la vérification en deux étapes et en avez ajouté un second, vous pouvez :
+
+
+
Choisir le lien « essayer une autre méthode » dans l’écran sur lequel vous avez reçu votre code;
+
+
Choisir votre second numéro de téléphone pour qu’on vous envoie un autre code;
+
Entrer le code envoyé à votre autre téléphone;
+
Vous connecter
+
+
Si vous choisissez un numéro de téléphone pour la vérification en deux étapes et que vous n’en ajoutez pas un deuxième, et que vous avez perdu l’accès à votre numéro de téléphone, malheureusement, vous ne pouvez pas récupérer votre compte. Vous devrez créer un nouveau compte.
+
+
+
+
+Comment puis-je mettre à jour un numéro de téléphone enregistré?
+
+
Si vous devez modifier un numéro de téléphone que vous avez enregistré, vous devrez ajouter le nouveau numéro de téléphone et supprimer celui qui n’est plus nécessaire :
+
+
+
Ouvrez une session comme vous le feriez normalement avec votre nom d’utilisateur, votre mot de passe et le processus de vérification en deux étapes
+
Lorsque vous arrivez à l’écran Vous vous êtes connecté avec succès, sélectionnez le bouton Paramètres de connexion
+
+
Lorsque vous arrivez à l’écran Paramètres de connexion, sélectionnez l’option Ajouter un numéro de téléphone mobile et suivez les étapes pour ajouter votre numéro de téléphone mobile nouveau ou mis à jour
+
+
+
Pour supprimer l’ancien numéro de téléphone :
+
+
+
À l’écran principal Paramètres de connexion, sélectionnez l’option Modifier à côté du numéro de téléphone que vous voulez supprimer
+
À l’écran Modifier le numéro de téléphone, sélectionnez l’option Supprimer
+
+
Pour des raisons de sécurité, vous devrez saisir le numéro de téléphone au complet pour confirmer la suppression
L’équipe de gestion des justificatifs externes de services partagés Canada (SPC) a mis en place l’authentification multifacteur en tant que service 3.0 (AMFaaS 3.0) pour le service de groupeurs de la fédération émettrice des justificatifs du gouvernement du Canada (FJGC) le 31 juillet 2023.
+
+
Dans le cadre de ce déploiement, toutes les parties utilisatrices (PU) de la FJGC ont migré vers la plateforme AMFaaS 3.0, à moins qu’elles n’aient choisi de se retirer de la plateforme en suivant un processus prédéfini.
+
+
Le service d’Authenti-Canada utilise la plateforme authentification multifacteur en tant que service 2.0 (AMFaaS 2.0) de SPC pour fournir une authentification multifactorielle par mot de passe dynamique temporel aux clients de l’Authenti-Canada qui ont activé l’AMF pour leurs services.
+
+
Par conséquent, le service d’Authenti-Canada s’est retiré de la plateforme AMFaaS 3.0 de SPC et continuera à utiliser la plateforme AMFaaS 2.0. Les PU intégrées au service d’Authenti-Canada et utilisant l’AMF continueront à utiliser l’AMF existant. Il n’y aura pas d’impact sur les clients d’Authenti-Canada et aucune action ne sera requise de leur part.
La nouvelle ICGA de SaaS, en cours d’acquisition pour remplacer Authenti-Canada, offrira à l’avenir des choix supplémentaires en matière d’authentification multifactorielle. Si vous souhaitez qu’on vous informe de l’avancement du projet de ICGA, n’hésitez pas à utiliser la boîte aux lettres d’Authenti-Canada.
+
+
31 juillet 2023
+
Phase de maintenance d’Authenti-Canada
+
+
Afin d’accorder la priorité à une solution de logiciel sous forme de service (SaaS) pour l’identité des clients et gestion de l’accès (ICGA) destinée aux entreprises, le service Authenti-Canada entame une phase de maintenance. Par conséquent, le produit minimum viable (PMV) de Authenti-Canada ne fera l’objet d’aucune nouvelle amélioration ou intégration.
+
+
Le service continuera de fonctionner avec les niveaux de soutien actuels pour les intégrations et les clients existants. Les mises à jour se limiteront à la correction de bogues et à l’installation de rustines de sécurité. Autrement dit, aucune nouvelle application ne sera intégrée dans le PMV d’Authenti-Canada.
+
+
Tous les clients potentiels devront utiliser le service de regroupement de la fédération des
+justificatifs du gouvernement du Canada (FJGC) de services partagés Canada (SPC), et ce, jusqu’à la mise en place de la solution de ICGA pour les entreprises. Le contrat de SaaS pour la ICGA devrait être accordé au printemps 2024 dans le cadre de la planification des solutions propres au ministère qui feront l’objet d’une intégration ultérieure.
+
+
Les clients du service Authenti-Canada seront migrés vers la nouvelle solution de ICGA une fois qu’on aura obtenu et déployé la solution. Soyez assurés que nous fournirons d’autres détails sur l’état de l’approvisionnement en matière de IGCA, de même que les plans de migration, lorsque nous disposerons de renseignements plus précis.
+
+
Veuillez envoyer un message à la boîte aux lettres du Service de gestion des justificatifs externes (GJE) de SPC, à l’adresse (ecm-gje@ssc-spc.gc.ca), afin d’obtenir des renseignements supplémentaires sur le service de regroupement de la FJGC.
+
+
Si vous avez des questions ou des préoccupations concernant l’approvisionnement en matière de ICGA, n’hésitez pas à envoyer un message à la boîte aux lettres d’Authenti-Canada.
Avis de confidentialité pour les utilisateurs d’Authenti-Canada
+
+
Sur cette page
+
+
+
+
Définition générale du service
+
+
Authenti-Canada est un service en ligne qui offre un moyen sûr et facile d’accéder à de multiples programmes et services gouvernementaux. À l’aide d’un justificatif comme CléGC ou d’un partenaire bancaire, le service d’authentification multifacteur (AMF) d’Authenti-Canada vous permet d’accéder en toute sécurité aux services des organismes gouvernementaux.
+
+
Ce service est conçu pour vous permettre de gérer les prestations, les services et les demandes fédéraux plus facilement et de façon plus sécuritaire. Authenti-Canada collabore avec d’autres organismes fédéraux (appelés « parties utilisatrices ») pour vous donner accès à leurs services.
+
+
Authenti-Canada prend la sécurité au sérieux et utilise des mesures strictes pour protéger votre compte. Le service respecte également votre vie privée en ne recueillant auprès de vous que les renseignements nécessaires et en ne les partageant qu’avec les parties utilisatrices qui en ont besoin pour vous donner accès à leurs services.
+
+
Nous recueillons vos renseignements personnels
+
+
Vos renseignements personnels comprennent votre numéro de téléphone. Les renseignements sont recueillis uniquement dans le but de fournir et de gérer l’accès aux systèmes et aux applications du gouvernement du Canada et de vous fournir les communications nécessaires. Si vous ne souhaitez pas utiliser un numéro de téléphone pour accéder aux services électroniques, vous pouvez demander le service par téléphone, par télécopieur, par courrier ou en personne.
+
+
Pour plus de détails, consultez les coordonnées du service de la partie utilisatrice correspondante.
+
+
Les renseignements personnels recueillis et utilisés pour s’inscrire à un service sont stockés dans le fichier de renseignements personnels PCU 607. Ces renseignements personnels sont conservés pendant au moins deux ans.
+
+
Nous avons recours à l’analyse du Web
+
+
Nous utilisons un logiciel d’analyse pour recueillir et stocker des renseignements sur votre visite sur notre site. Ces renseignements comprennent :
+
+
+
des renseignements environnementaux tels que l’emplacement de votre adresse IP, la langue dans laquelle vous naviguez et les spécifications techniques de l’appareil et du navigateur que vous utilisez;
+
des renseignements comportementaux tels que la date et l’heure de votre visite, les pages que vous visitez, les liens sur lesquels vous avez cliqué sur le site et le nom du domaine à partir duquel vous accédez à Internet;
+
des renseignements d’acquisition tels que l’adresse Internet du site Web d’où vous venez, s’il vous a mené directement au service AFM Authenti-Canada
+
Si votre navigateur accepte les témoins, nous pouvons utiliser un témoin temporaire pour savoir combien de visiteurs différents accèdent à Authenti-Canada
+
+
+
Ces données sont utilisées pour :
+
+
+
Nous aider à rendre notre site plus utile en utilisant des statistiques évaluant les services qui intéressent le plus ou le moins nos clients et déterminer les spécifications techniques de conception;
+
Déterminer la performance du système ou les points problématiques;
+
Protéger la sécurité de notre site Web, et détecter les tentatives non autorisées de téléverser ou de modifier des renseignements, ou de causer d’autres dommages;
+
Relever et résoudre les problèmes ou difficultés que vous connaissez en tentant d’ouvrir une session sur nos sites.
+
+
+
Nous partageons certains renseignements
+
+
En cas de suspicion d’atteinte à la sécurité ou à la vie privée, les renseignements personnels peuvent être partagés avec les responsables ministériels de la sécurité et de l’accès à l’information et à la vie privée, ainsi qu’avec le ministère ou l’organisme du gouvernement fédéral qui recueille et utilise les renseignements personnels considérés comme ayant été compromis. Les renseignements peuvent être partagés avec les autorités chargées de l’application de la loi si nous soupçonnons des activités criminelles ou avec d’autres services qui effectuent une surveillance électronique des réseaux. Ces renseignements ne sont pas utilisés à d’autres fins et leur destruction régulière est prévue conformément à la Loi sur la Bibliothèque et les Archives du Canada et à la Loi sur la protection des renseignements personnels.
+
+
Nous nous abstenons :
+
+
d’autoriser d’autres services à utiliser vos renseignements pour tout ce qui n’est pas lié à Authenti-Canada;
+
de vendre ou de louer vos renseignements personnels;
+
de partager vos renseignements personnels à des fins promotionnelles.
La loi exige que nous protégions votre vie privée. Vous avez le droit d’accéder à vos renseignements personnels et de les consulter. Utilisez votre service AFM d’Authenti-Canada pour vérifier, corriger ou mettre à jour vos renseignements.
+
+
Si vous avez des questions, des préoccupations ou des plaintes concernant cet avis ou l’application de la Loi sur la protection des renseignements personnels dans le cadre de votre service AFM d’Authenti-Canada, veuillez communiquer avec la Division de l’accès à l’information et de la protection des renseignements personnels par courriel à l’adresse atip-aiprp@ssc-spc.gc.ca ou par écrit à l’adresse suivante :
+
+
+Directeur, Accès à l’information et protection des renseignements personnels
+
+
Services partagés Canada
+
+
CP 9808, Station T, CSC
+
+
Ottawa (Ontario) K1G 4A8
+
+
+Vous avez également le droit de nous faire part de vos préoccupations concernant la manière dont nous traitons vos renseignements personnels. Pour en savoir plus ou pour déposer une plainte officielle, communiquez avec le Commissaire à la protection de la vie privée du Canada.
+
+
Chaque partie utilisatrice dispose également de sa propre politique de confidentialité. Pour de plus amples renseignements, veuillez consulter les conditions générales et les avis de confidentialité correspondants sur la page Web de chaque partie utilisatrice.
Lorsque vous contribuez, veuillez également publier des commentaires et discuter
+des modifications que vous souhaitez apporter par l’entremise des enjeux
+(Issues).
+
+
N’hésitez pas à proposer des modifications en créant des demandes de tirage
+(Pull Requests). Si vous n’avez pas accès au mode de rédaction, la modification
+d’un fichier créera une copie (Fork) de ce projet afin que vous puissiez
+enregistrer les modifications que vous proposez. Le fait de proposer une
+modification à un fichier l’écrira dans une nouvelle branche dans votre copie
+(Fork), de sorte que vous puissiez envoyer une demande de tirage (Pull Request).
+
+
Si c’est la première fois que vous contribuez à GitHub, ne vous en faites pas!
+Faites-nous part de vos questions.
+
+
Sécurité
+
+
Ne publiez aucun problème de sécurité sur le dépôt publique! Voir
+SECURITY.md
Collection automatique de l’identificateur par paire
+
+
L’un des principaux objectifs de la plateforme d’acceptation d’Authenti-Canada
+est de faciliter le remplacement des anciens systèmes de fournisseurs de
+services de justificatifs d’identité, en particulier les anciens systèmes CléGC
+et Service de courtier de justificatifs d’identité qui sont utilisés depuis
+2011.
+
+
L’une des principales conditions préalables à la mise hors service ou au
+remplacement de ces anciens systèmes est de déplacer les mappages
+d’identificateur par paire actuellement détenus par ces services plus anciens
+vers la plateforme d’acceptation, de sorte que les inscriptions des utilisateurs
+avec les parties de confiance ne soient pas touchées lorsque les parties de
+confiance passent à la plateforme Authenti-Canada.
+
+
La plateforme d’acceptation Authenti-Canada met en œuvre une fonctionnalité qui
+permet de copier automatiquement les mappages des identifiants par l’utilisateur
+au moyen d’une paire à partir d’un service de justificatif d’identité vers la
+plateforme d’acceptation la première fois qu’ils sont utilisés. Ils sont ensuite
+stockés par la plateforme d’acceptation pour une utilisation future, de sorte
+que le mappage stocké par le service de justificatif d’identité n’est plus
+nécessaire. Cela réduit les risques et les efforts requis pour déplacer ces
+données. Au fil du temps, les données cartographiques des utilisateurs actifs
+sont progressivement « recueillies » par la plateforme d’acceptation, ce qui
+réduit la nécessité de copier régulièrement les données manuellement au moyen
+d’une sorte de « transfert en vrac ».
+
+
Fonctionnement
+
+
+
+
La plateforme d’acceptation effectue la collecte automatique des mappages
+d’identificateurs par paire dans le cadre du processus normal de connexion
+d’utilisateur, en envoyant une deuxième demande d’authentification SAML aux
+fournisseurs de services de justificatifs, le cas échéant.
+
+
+
+
Le processus commence lorsqu’une partie de confiance envoie une demande
+d’authentification à la plateforme d’acceptation, à l’aide d’OpenID Connect ou
+de SAML.
+
+
+
La plateforme d’acceptation envoie ensuite une demande d’authentification au
+FSI en son propre nom. Elle demande l’identificateur par paire que le FSI a
+créée pour Authenti-Canada.
+
+
+
À la réception de l’assertion SAML du FSI, la plateforme d’acceptation
+recherche l’utilisateur dans son propre référentiel de profils d’utilisateur.
+
+
+
La plateforme d’acceptation vérifie ensuite si elle dispose déjà d’un mappage
+d’identificateur par paire pour l’utilisateur authentifié avec la partie de
+confiance requérante. Dans l’affirmative, la collecte n’est pas requise, le flux
+de connexion se termine normalement et la plateforme d’acceptation renvoie
+l’identificateur par paire approprié à la partie de confiance (PC).
+
+
+
Toutefois, si la plateforme d’acceptation ne possède pas de mappage
+d’identificateur par paire pour l’utilisateur authentifié avec la partie de
+confiance requérante, elle envoie une deuxième demande d’authentification au FSI
+au nom de la partie de confiance.
+
+
+
Si le FSI a un identificateur par pair existant pour l’utilisateur avec la PC
+requérante, il retourne cet identificateur dans une assertion et la plateforme
+Acceptantion l’ajoute à son propre référentiel utilisateur. À ce stade,
+l’identificateur a été « collecté » par la plateforme d’acceptation et sera
+utilisé chaque fois que l’utilisateur se connectera à cette PC à l’avenir
+(conformément à l’étape 4 ci-dessus).
+
+
+
Si le FSI ne possède pas d’identificateur par pair existant pour
+l’utilisateur avec la PC requérante, il n’y a donc rien à « collecter », de
+sorte que la plateforme d’acceptation crée un nouvel identificateur pour
+l’utilisateur avec la PC requérante, et cet identificateur est utilisé pour
+toutes les connexions futures.
+
+
+
+
Détails techniques
+
+
Lors de l’envoi d’une deuxième demande d’authentification au FSI pour le compte
+ou la partie de confiance, la plateforme d’acceptation utilise l’élément
+<NameIDPolicy> du message SAML <AuthnRequest>. Plus précisément, il utilise les
+deux attributs suivants de l’élément <NameIDPolicy> :
+
+
+
+
La valeur de l’attribut SPNameQualifier est renseignée avec l’entité de
+l’ancien ID SAML de la partie de confiance requérante, pour indiquer que la
+plateforme d’acceptation demande l’identificateur par paire de PC au lieu du
+sien.
+
+
+
La valeur de l’attribut AllowCreate est définie sur "false", pour indiquer
+au FSI qu’il ne doit pas créer un nouvel identificateur par paire pour la PC
+si celui-ci n’en a pas déjà un.
+
+
+
+
Voici un exemple d’une demande d’authentification émise par la plateforme
+d’acceptation en son nom propre :
QÀ quoi ressemble l’expérience de l’utilisateur? Doit-il saisir son mot de passe deux fois?
+
+
Ce processus tire parti des fonctionnalités d’authentification unique inhérentes
+à SAML, de sorte que l’utilisateur n’aura pas à s’authentifier plus d’une fois,
+si ce n’est du tout :
+
+
+
Si l’utilisateur n’est pas encore connecté au FSI, ou s’il est connecté,
+mais que la fenêtre connexion unique (20 minutes avec le FSI de la FJGC) a
+expiré, il sera invité à s’authentifier après la première demande
+d’authentification SAML. Une fois qu’ils se sont connectés avec succès au FSI,
+la plateforme d’acceptation envoie ensuite la deuxième demande
+d’authentification, dont une partie plus tard, dans la fenêtre
+d’authentification unique, de sorte qu’ils ne seront pas invités à se
+connecter une deuxième fois.
+
Dans le cas improbable où l’utilisateur est déjà connecté au FSI, mais que
+la fenêtre d’authentification unique expire dans quelques secondes entre les
+deux demandes d’authentification, alors la connexion unique s’appliquera à la
+première demande, mais pas à la seconde. Encore une fois, l’utilisateur n’a
+besoin de fournir ses informations d’identification qu’une seule fois.
+
Si l’utilisateur est déjà connecté au FSI et que les deux demandes
+d’authentification sont traitées dans la fenêtre de connexion unique, le FSI
+n’invite pas l’utilisateur à saisir à nouveau ses informations
+d’identification. La partie de confiance peut remplacer ce comportement en
+spécifiant prompt="login" (pour OpenID Connect) ou forceAuthn="true" (dans
+SAML) dans sa demande d’authentification pour se connecter au Canada, où la
+plateforme d’acceptation spécifiera forceAuthn="true" sur sa première
+demande au FSI, mais pas la seconde.
+
+
+
Qu’advient-il si l’utilisateur du clavier change? Y a-t-il un risque que la plateforme d’acceptation recueille le mauvais identificateur appartenant à la mauvaise personne?
+
+
Ce scénario possible peut survenir dans les cas où plusieurs personnes partagent
+le même appareil, et l’une d’elles a laissé l’appareil sans surveillance pendant
+qu’elles étaient encore connectées au FSI. À titre d’exemple :
+
+
Prenons l’exemple de deux utilisateurs, Alice et Bob, qui ont tous deux accès au
+même ordinateur partagé :
+
+
+
Alice se connecte à la partie de confiance de la FJGC en utilisant sa CléGC,
+ mais s’éloigne ensuite de l’ordinateur sans se déconnecter.
+
Bob s’assoit ensuite sur le même ordinateur et tente de se connecter à la
+ partie de confiance Auntheti-Canada, quelques secondes seulement avant
+ l’expiration de la fenêtre de 20 minutes de connexion unique d’Alice.
+
La plateforme d’acceptation envoie la première demande d’authentification à
+ CléGC et reçoit en retour l’identificateur par paire d’Alice.
+
La fenêtre connexion unique d’Alice expire ensuite en quelques secondes avant
+ que la plateforme d’acceptation envoie la deuxième demande d’authentification.
+ CléGC demande à Bob d’entrer ses informations d’identification de CléGC, puis
+ retourne l’identificateur par paire de Bob à la plateforme d’acceptation.
+
La plateforme d’acceptation associe ensuite l’identificateur de la CléGC de
+ Bob au profil d’utilisateur d’Alice.
+
+
+
Afin d’éviter cela, la plateforme d’acceptation vérifie l’Index de session
+(SessionIndex)des deux assertions SAML et s’assure qu’elles correspondent
+avant d’accepter l’identificateur collecté.
+
+
Les identificateurs par paires SAML émis par un fournisseur d’identité sont censés être propres au fournisseur de services SAML (PC). Comment Authenti-Canada est-il autorisé à obtenir les identificateurs générés pour un autre fournisseur de services SAML?
+
+
Les spécifications SAML permettent l’existence d’affiliations : groupes d’un ou
+de plusieurs fournisseurs de services qui partagent le même identificateur par
+paire pour un utilisateur donné. Lorsqu’une partie de confiance se déconnecte de
+la FJGC pour se connecter à Authenti-Canada, une nouvelle affiliation SAML est
+définie, au moyen des métadonnées SAML, qui permettent à la plateforme
+d’acceptation d’obtenir les identificateurs par paire qui ont été créés à
+l’origine pour la PC.
Environnement d’essai pour l’acceptation des clients (EEAC)
+
+
L’Environnement d’essai pour l’acceptation des clients d’Authenti Canada est accessible
+à toute personne du gouvernement du Canada qui souhaite:
+
+
+
Apprendre à utiliser OpenID Connect pour l’intégrer à Authenti-Canada
+
Développer et tester de nouvelles applications de prestation de services numériques
+
+
+
L’intégration d’un environnement de bac à sable, de développement ou de test pour Authenti-Canada
+est rapide et facile. Il vous suffit d’envoyer un courriel à Signin-AuthentiCanada@tbs-sct.gc.ca
+en précisant des renseignements de base sur votre application, comme le service infonuagique ou la
+plateforme de développement que vous utilisez. L’équipe d’Authenti-Canada vous aidera à connecter
+votre application et vérifier qu’elle fonctionne, souvent dans un délai d’un ou deux jours.
La plateforme Authenti-Canada fonctionne comme une autorité de gestion de
+session qui coordonne de façon centralisée les sessions des utilisateurs dans
+plusieurs applications de parties de confiance (PC). La plateforme comporte deux
+caractéristiques clés qui la soutiennent : authentification unique et
+déconnexion unique.
+
+
Authentification unique
+
+
Une fois qu’un utilisateur a utilisé avec succès un justificatif quelconque ou
+un service d’identité numérique de confiance pour s’authentifier auprès d’une
+PC, Authenti-Canada peut lui permettre de s’authentifier en silence auprès
+d’autres PC, sous réserve d’une période d’attente d’authentification unique. La
+plateforme y parvient en créant sa propre session avec l’utilisateur lors de sa
+première connexion, puis en ne les invitant pas à se réauthentifier lorsqu’ils
+se connectent à d’autres PC pendant un délai d’inactivité spécifiée.
+
+
La fenêtre d’attente de l’authentification unique démarre chaque fois qu’un
+utilisateur saisit son mot de passe correct à un fournisseur de justificatif
+d’identité (FJI) et se termine après une période spécifiée. Par défaut, il
+s’agit de 20 minutes, mais les parties qui se connectent au Canada peuvent
+modifier ce délai si elles le souhaitent. Il est toutefois important de noter
+que la fenêtre d’authentification unique des services d’authentifiant CléGC et
+le service de courtier de justificatifs d’identité, qui est également de 20
+minutes, ne peut pas être modifié, elle ne peut être désactivée (appelée
+authentification forcée). Dans toute situation où le délai d’attente « codé en
+dur » pourrait entrer en conflit avec le délai d’attente préféré d’une partie de
+confiance, la plateforme Authenti-Canada synchronisera automatiquement les deux
+et résoudra le conflit.
+
+
Notez que pour que l’authentification unique fonctionne, l’utilisateur doit
+utiliser les mêmes informations d’identification ou la même identité numérique
+de confiance pour accéder à tous les services gouvernementaux numériques. À
+l’heure actuelle, cela n’est pas possible puisque tous les services du
+gouvernement du Canada n’acceptent pas les mêmes justificatifs. Par exemple,
+l’accès aux services fiscaux en ligne fournis par l’Agenge du revenu du Canada
+n’est actuellement pas possible à l’aide d’un justificatif d’identité de CléGC.
+Par conséquent, les utilisateurs qui ont choisi d’utiliser un justificatif de
+CléGC ne peuvent pas s’inscrire à Mon dossier pour les particuliers de
+l’ARC.
+
+
Déconnexion unique
+
+
Lorsqu’un utilisateur a visité plusieurs sites Web (applications de partie de
+confiance) au cours de la même session, la plateforme Authenti-Canada a la
+capacité de coordonner de manière centralisée une déconnexion unique. Avec une
+déconnexion unique, l’utilisateur n’a qu’à cliquer sur un bouton de déconnexion
+sur le site qu’il visite actuellement, et Authenti-Canada les déconnectera
+ensuite de tous les autres sites qu’il a visités pendant sa session.
+
+
La propagation de la déconnexion sur tous ces sites peut utiliser le mécanisme
+de déconnexion OpenID Connect
+Front-Channel,
+le mécanisme de déconnexion OpenID Connect
+Back-Channel ou
+le profil de déconnexion SAML à l’aide de
+liaisons
+de canal frontal (HTTP-Redirect) ou de canal secondaire (SOAP). La plateforme
+Authenti-Canada appuie tous ces éléments.
+
+
Les protocoles OpenID Connect (OIDC) et SAML suivent la même séquence d’événements de base :
+
+
+
Comme un utilisateur visite plusieurs sites Web (applications) au cours de la
+même session, la plateforme Authenti-Canada permet de suivre les sites qu’il
+a visités.
+
Lorsque l’utilisateur clique sur un bouton de déconnexion sur l’un des sites
+qu’il visite, l’application Web de ce site envoie une demande de déconnexion
+à la plateforme Authenti-Canada.
+
Authenti-Canada envoie ensuite une demande de déconnexion à tous les autres
+sites que l’utilisateur a visités, afin qu’il puisse déconnecter
+l’utilisateur.
+
+
+
Transition et coexistence
+
+
Il y aura une période de transition prolongée à mesure que les applications PC
+se connecteront à Authenti-Canada et se déconnecteront progressivement un à un
+de la fédération des justificatifs du gouvernement du Canada (FJGC) CléGC et
+Services de courtier de justificatifs d’identité. Pendant cette période de
+transition, la plateforme Authenti-Canada servira d’autorité de gestion de
+session pour les applications qui y sont connectées, tandis que les services
+CléGC et services de courtier de justificatifs d’identité serviront d’autorité
+de gestion de session pour les applications qui y sont connectées.
+
+
Cela crée une obligation pour Authenti-Canada de coordonner une déconnexion
+unique avec CléGC et les services de courtier de justificatifs d’identité
+(SCJI), ainsi qu’avec ses propres PC. La plateforme y parvient en appuyant le
+profil de déconnexion unique SAML dans le cadre de son intégration, en tant que
+fournisseur de justificatifs d’identité proxy SAML, avec CléGC et services de
+courtier de justificatif d’identité. La plateforme Authenti-Canada est en mesure
+de coordonner une déconnexion unique avec la fédération des justificatifs du
+gouvernement du Canada (FJGC) dans les deux sens. C’est-à-dire, peu importe si
+l’utilisateur se déconnecte d’abord d’Authenti-Canada ou s’il se déconnecte
+d’abord de la FJGC.
+
+
Scénario 1 : Un utilisateur se déconnecte d’abord d’Authenti-Canada
+
+
L’exemple suivant illustre comment une déconnexion unique est réalisée dans le
+cas où l’utilisateur clique sur un bouton de déconnexion sur un site de la
+partie de confiance qui est connecté à Authenti-Canada.
+
+
+
+
Le scénario commence lorsqu’un utilisateur clique sur un bouton de déconnexion
+sur le site de la partie de confiance qu’il utilise. Lorsque cela se produit :
+
+
+
L’application de la partie de confiance déconnecte l’utilisateur localement
+d’abord, puis redirige le navigateur vers le point de terminaison OpenID
+Connect de session des plateformes d’acceptation.
+
Si des parties de confiance qui participent à la session appuient la
+déconnexion en mode canal arrière de Connexion OpenID, la plateforme
+d’acceptation envoie d’abord un jeton de déconnexion à tous, à travers un
+POST HTTP à leurs URI de déconnexion en mode canal arrière enregistré pour
+déclencher les actions de déconnexion de ces PC. S’il y a plusieurs parties
+de confiance, ces demandes sont toutes envoyées simultanément, en parallèle.
+
Une fois la déconnexion canal arrière terminée, la plateforme d’acceptation
+retourne une page de propagation de déconnexion
+HTML au navigateur. Cette page
+contient un certain nombre d’éléments
+iframe.
+L’attribut src (source) de tous les éléments, sauf un, pointe vers l’URI de
+déconnexion du canal avant de l’un des sites de partie de confiance
+d’Authenti-Canada où l’utilisateur s’est connecté pendant sa session en
+cours. Dans le diagramme, ces autres sites sont désignés comme « autres PC de
+l’OIDC ». L’attribut src de l’iframe final pointe vers un point terminal URI
+du Cadre d’acceptation de la plateforme d’acceptation.
+
Dès réception de la page de propagation, le navigateur commence à charger en
+parallèle l’intégralité de la valeur des _iframe_s, en envoyant de manière
+asynchrone une requête HTTP GET à l’URI src de chaque _iframe.
+
Lorsque les autres parties de confiance reçoivent ces demandes, elles
+déconnectent l’utilisateur localement, puis retournent une réponse HTTP au
+navigateur.
+
Lorsque le cadre d’acceptation de la plateforme d’acceptation reçoit sa
+demande, il crée un message SAML de demande de déconnexion, puis redirige le
+navigateur avec ce message (dans le cadre iframe) vers l’ancien PSC (CléGC ou
+FJI) avec lequel l’utilisateur a choisi de se connecter.
+
Le FSI déconnecte ensuite l’utilisateur de ses informations d’identification.
+Si l’utilisateur a visité des sites qui sont encore reliés directement au FSI
+(au lieu d’Authenti-Canada), il propagera également la déconnexion à tous ces
+sites, progressivement, une à une.
+
Le FSI redirige ensuite le navigateur (dans l’iframe) vers le Cadre
+d’acceptation de la plateforme d’acceptation avec un message SAML
+LogoutResponse. Le Cadre d’acceptation traite ce message, puis envoie une
+réponse HTTP au navigateur.
+
La page de propagation de déconnexion comporte un gestionnaire d’événements
+d’erreur global qui sera déclenché si un type d’erreur se produit alors que
+tous les iframes propagent la déconnexion vers divers sites de manière
+asynchrone.
+
Si l’une des iframes échoue ou s’interrompt, si la réponse de déconnexion
+SAML du FSI indique une erreur, alors le gestionnaire onerrorevent redirige
+le navigateur vers une page d’erreur, avertissant l’utilisateur qu’il ne
+peut pas être complètement déconnecté et lui recommandant de fermer son
+navigateur.
+
Si toutes les iframes propagent avec succès la déconnexion vers leur site
+cible, le navigateur est redirigé vers la page d’accueil de déconnexion du
+site où l’utilisateur a initialement cliqué sur « Déconnexion » (l’URI
+post_déconnexion_redirect_uri de la partie de confiance).
+
+
+
Scénario 2 : Un utilisateur se déconnecte d’abord du FJGC
+
+
L’exemple suivant illustre comment une déconnexion unique est réalisée dans le
+cas où l’utilisateur clique sur un bouton de déconnexion sur un site de la
+partie de confiance qui est toujours connecté à l’un des services de
+justificatif d’identification de la FJGC (CléGC ou service de courtier de
+justificatif d’identité).
+
+
+
+
Le scénario commence lorsqu’un utilisateur clique sur un bouton de déconnexion
+sur le site de la partie de confiance qu’il utilise. Lorsque cela se produit :
+
+
+
L’application de la partie de confiance déconnecte l’utilisateur localement
+d’abord, puis redirige le navigateur vers le point terminal de déconnexion
+unique SAML du FSI avec un message SAML LogoutRequest.
+
Si l’utilisateur a visité d’autres sites qui sont toujours connectés
+directement au FSI (au lieu de l’Authenti-Canada), il propagera d’abord la
+déconnexion de tous ces sites à l’aide de la déconnexion SAML dans le canal
+arrière (SOAP). Cela se fait un à un, pendant que l’utilisateur attend,
+ensuite il sera alors complètement déconnecté de la FJGC.
+
Pour déconnecter l’utilisateur de l’Authenti-Canada, le FSI de la FJGC
+redirige ensuite le navigateur vers le Cadre d’acceptation de
+l’Authenti-Canada avec un message SAML LogoutRequest.
+
Le cadre d’acceptation crée ensuite une demande de déconnexion OpenID Connect
+et redirige le navigateur vers le point terminal de session du fournisseur
+d’OpenID de la plateforme d’acceptation.
+
Si des parties de confiance qui participer à la session de la plateforme
+d’acceptation prennent en charge la déconnexion, la plateforme d’acceptation
+envoie d’abord un jeton de déconnexion à tous, via un POST HTTP à son URI de
+déconnexion en mode canal arrière enregistré. Cela déclenche les actions de
+déconnexion de chacun de ces PC. S’il y a plusieurs parties de confiance, ces
+demandes sont toutes envoyées simultanément, en parallèle.
+
Une fois l’ouverture de session dans le canal arrière terminée, la plateforme
+d’acceptation retourne une page de propagation de déconnexion
+HTML. Cette page contient un
+certain nombre d’éléments
+iframe.
+L’attribut src (source) de chaque élément iframe pointe vers l’URI de
+déconnexion du canal avant de l’un des sites de la partie de confiance où
+l’utilisateur s’est connecté pendant sa session en cours. Dans le diagramme,
+ces autres sites sont désignés comme « autres PC de l’OIDC ». L’attribut src
+de l’iframe final pointe vers un point terminal URI du Cadre d’acceptation de
+la plateforme d’acceptation.
+
Dès réception de la page de propagation, le navigateur commence à charger en
+parallèle l’intégralité de la valeur de _iframe_s, en envoyant de manière
+asynchrone une requête HTTP GET à l’URI src de chaque iframe.
+
Lorsque les autres parties de confiance reçoivent ces demandes, elles
+déconnectent l’utilisateur localement, puis retournent une réponse HTTP au
+navigateur.
+
La page de propagation de déconnexion comporte un gestionnaire d’événements
+d’erreur global qui sera déclenché si un type d’erreur se produit alors que
+tous les _iframe_s propagent la déconnexion vers divers sites de manière
+asynchrone.
+
Si l’une des iframes échoue ou s’interrompt, le gestionnaire onerrorevent
+redirige le navigateur vers le Cadre d’acceptation avec une requête HTTP
+indiquant un problème de déconnexion.
+
+
Le Cadre d’acceptation redirigera ensuite le navigateur vers le FSI avec
+ un message SAML LogoutResponse portant un code de statut urn : oasis :
+ names : tc : SAML : 2,0 : status : Responder.
+
La FSI redirigera ensuite le navigateur vers sa propre PC avec un message
+ LogoutResponse portant un code de statut de haut niveau
+ urn:oasis:names:tc:SAML:2.0:status:Success et un code de statut de
+ second niveau urn:oasis:names:tc:SAML:2.0:status:PartialLogout.
+
Cela entraînera l’affichage de la page d’erreur PC du SAML, avertissant
+ l’utilisateur qu’il n’est peut-être pas complètement déconnecté et lui
+ recommandant de fermer son navigateur.
+
+
+
Si toutes les iframes propagent correctement la déconnexion vers leur site
+cible, le code JavaScript redirige le navigateur vers le Cadre d’acceptation
+avec une demande HTTP indiquant une déconnexion réussie.
+
+
Le Cadre d’acceptation redirigera ensuite le navigateur vers le FSI
+avec un message SAML LogoutResponse portant un code de statut
+urn:oasis:names:tc:SAML:2.0:status:Success.
+
Le FJI redirigera ensuite le navigateur vers sa propre PC avec un message
+LogoutResponse portant un code de statut de haut niveau
+urn:oasis:names:tc:SAML:2.0:status:Success et aucun code de statut de
+niveau supérieur.
+
Cela entraînera l’affichage de la page de déconnexion ou d’accueil
+habituelle de SAML PC.
La plateforme Authenti-Canada fournit un service parapluie qui agit comme un intermédiaire de confiance entre
+les fournisseurs de services d’identification et les programmes gouvernementaux qui les utilisent pour fournir
+des services à leurs clients externes (par exemple, des particuliers, des entreprises et des représentants).
+
+
Caractéristiques principales
+
+
+
Premier facteur d’authentification (nom d’utilisateur et mot de passe) au moyen:
+
+
du justificatif portant la marque du gouvernement du Canada: “CléGC”
+
+
des justificatifs d’identité des services bancaires en ligne, par l’entremise d’un service de courtier de justificatifs d’identité (SCJ): “Gouvernement Connecté par Vérifiez.Moi”
+
Les applications s’intègrent à la plateforme Authenti-Canada en utilisant le protocole normalisé de l’industrie OpenID Connect (en anglais). OpenID Connect est largement pris en charge par les plus importants produits soit:
+
+
+
Les produits infonuagiques de service comme logiciel (SaaS) et de plateformes en tant que service (PaaS), y compris
+
L’environnement de production Authenti-Canada est en service depuis mars 2021.
+
+
Autorisation de sécurité
+
+
La sécurité de l’environnement de production Authenti-Canada a été évaluée et autorisée à authentifier les utilisateurs au nom des applications des parties utilisatrices:
pour laquelle la sensibilité (confidentialité, intégrité et disponibilité) de toute donnée à traiter, à stocker, à transmettre sur ou par les parties utilisatrices ne dépasse pas le niveau Protégé B, Intégrité moyenne, Disponibilité moyenne.
+
+
+
Disponibilité
+
+
L’environnement de production fonctionne 24 heures sur 24, 365 jours par année. Il a une disponibilité cible de 99,8 % calculée mensuellement et incluant les activités d’entretien prévues.
+
+
Rendement
+
+
Le rendement de l’environnement de production est calculé en mesurant le temps de réponse pour chaque demande HTTP reçue par le service. Ces demandes HTTP comprennent toutes les demandes reçues des navigateurs des utilisateurs pour les pages Web et le contenu Web connexe, ainsi que toutes les demandes aux interfaces de programmation d’applications (API) d’Authenti Canada provenant d’applications de parties utilisatrices.
+
+
La cible de rendement pour l’environnement de production est de répondre à 95 % des demandes HTTP dans un délai de 200 millisecondes ou moins, et de répondre à 99 % des demandes HTTP dans un délai de 500 millisecondes ou moins.
+
+
Capacité
+
+
L’environnement de production dispose actuellement d’une capacité suffisante pour authentifier jusqu’à 12 utilisateurs par seconde (43 200 par heure).
+
+
Sauvegarde et récupération des données
+
+
Toutes les données des utilisateurs et toutes les données de configuration des parties utilisatrices stockées dans l’environnement de production sont sauvegardées une fois par heure, toutes les heures, dans un stockage géographiquement redondant, ayant une durabilité d’au moins 99,99999999999999 % sur une année donnée.
+
+
Surveillance
+
+
La disponibilité et le rendement de l’environnement de production sont surveillés 24 heures sur 24, 365 jours par année. Cette surveillance est entièrement automatisée. Chaque fois qu’une interruption de disponibilité ou une dégradation de la performance est détectée, les membres de l’équipe de soutien d’Authenti-Canada sont automatiquement alertés par courriel et par texto.
La vitesse à laquelle l’équipe de soutien d’Authenti-Canada réagit aux incidents
+de service de production dépend du moment où l’incident est détecté ou signalé
+(toutes les heures indiquées sont en heure de l’Est):
+
+
+
+
+
Fenêtre d’occurrence de l’incident
+
Cible pour la réponse
+
+
+
+
+
Jours ouvrables, de 8 h à 17 h
+
Immédiatement
+
+
+
Jours ouvrables, de 17 h à 22 h
+
Faire au mieux
+
+
+
Fin de semaine et jours fériés, de 8 h à 22 h
+
Faire au mieux
+
+
+
Nuits, de 22 h à 8 h
+
Le jour suivant, comme indiqué ci-dessus
+
+
+
+
+
Entretien planifié
+
+
Maintenance des logiciels
+
+
Le logiciel Authenti-Canada exige une maintenance régulière afin de satisfaire aux niveaux
+de service établis et d’introduire de nouvelles fonctionnalités. Afin de réduire au minimum
+l’incidence sur les parties utilisatrices, les activités de maintenance qui nécessitent la
+mise hors ligne du service sont normalement prévues au cours d’une fenêtre de maintenance des
+logiciels définie, de 4 h à 5 h, heure de l’Est, les dimanches matin. Normalement, les parties
+utilisatrices ne sont pas informées des pannes prévues qui se produisent pendant cette période,
+qui durent normalement de 10 à 25 minutes. Dans des cas exceptionnels, lorsqu’une panne d’entretien
+doit être prévue à l’extérieur de cette fenêtre, l’équipe d’Authenti-Canada fournira aux parties
+utilisatrices un préavis d’au moins 7 jours.
+
+
Maintenance du réseau
+
+
L’environnement de production Authenti-Canada tire parti de l’infrastructure de sécurité du réseau
+qui est gérée par l’équipe de l’infrastructure et d’architecture d’entreprise du SCT. Cette infrastructure
+nécessite également un entretien périodique, qui est normalement prévu pour le jeudi suivant le deuxième
+mardi du mois, de 20 h à minuit. La maintenance prévue de l’infrastructure du réseau n’a pas toujours
+d’incidence sur la disponibilité du service, mais dans les cas où une panne est possible, l’équipe
+d’Authenti-Canada fera tout son possible pour informer les parties utilisatrices à l’avance.
+
+
Entretien imprévu
+
+
L’environnement de production Authenti-Canada tire parti du soutien en nuage, en plateforme et
+en infrastructure du SCT et de SPC. Ils se réservent le droit de prévoir des pannes d’entretien
+d’urgence pour les mises à jour critiques, dans le but de fournir aux parties utilisatrices un
+préavis d’au moins vingt quatre (24) heures. Les deux parties feront de leur mieux pour planifier
+ces pannes pendant les heures creuses et pour limiter leur survenue aux mises à niveau strictement
+nécessaires et à l’entretien requis. (Il convient de noter qu’il est question d’un entretien d’urgence
+et non d’un correctif d’urgence à la suite d’un incident.)
+
+
Dépendances des services
+
+
Le service Authenti-Canada tire parti de trois services de justificatifs d’identité fournis par
+Services partagés Canada, à savoir le service de justificatif portant la marque du gouvernement
+du Canada « CléGC », le service de courtier de justificatifs d’identité « Gouvernement Connecté
+par Vérifiez.Moi » et le service de deuxième facteur d’authentification. Les niveaux de service
+pour ces trois services sont distincts et séparés de ceux de l’environnement de production Authenti-Canada.
+
+
Soutien aux parties utilisatrices
+
+
Les parties utilisatrices peuvent signaler des incidents ou demander de l’aide au dépannage en envoyant
+un courriel à SignIn-AuthentiCanada@tbs-sct.gc.ca. L’équipe de soutien d’Authenti-Canada surveille cette
+boîte aux lettres de 8 h à 17 h les jours ouvrables.
La plateforme Authenti-Canada est construite sur le serveur Gluu (en anglais), une plateforme de gestion de l’identité et de l’accès en source libre.
+
+
La plateforme tire également parti de plusieurs services infonuagiques:
+
+
+
Infrastructure en tant que service : Machines virtuelles Azure, réseaux virtuels Azure, Gestionnaire de trafic Azure
+
PaaS/SaaS : Azure Storage, Coffre de clés Azure, Azure Functions, Azure Surveillance (Perspectives sur l’application, analyse des journaux), Azure DevOps, Azure DevTest Labs, GitHub
+
+
+
Architecture
+
+
+
+
Composantes
+
+
Cadre d’acceptation
+
+
Product: Gluu Passport (passeport pour Gluu)
+
+
Gluu Passport est une application Web Node.JS basée sur le cadre
+d’application Web Express et le logiciel de configuration
+d’authentification Passport.JS (en anglais).
+
+
Comme le nom l’indique, il s’agit de la composante « Acceptation » de la plateforme d’acceptation.
+Elle s’intègre avec les fournisseurs de justificatifs d’identité et les fournisseurs d’identité de
+confiance afin d’accepter des garanties de justificatifs d’identité et de justificatifs d’identité
+au nom des parties utilisatrices du gouvernement du Canada.
+
+
Authenti-Canada utilise une version du Gluu Passport qui a été personnalisée pour prendre en charge
+certaines fonctionnalités uniques qui appuient la coexistence avec les anciens services de justificatifs
+d’identité de la fédération des justificatifs du gouvernement du Canada et leur transition, en particulier:
+
+
+
Elle a été adaptée pour appuyer à la fois la préservation et la migration en temps réel des
+identificateurs anonymes persistants (IAP) existants de l’utilisateur du fournisseur de justificatifs
+d’identité (FJI) vers la plateforme d’acceptation, de sorte que la transition n’ait aucune incidence sur
+l’inscription des utilisateurs finaux auprès des parties utilisatrices actuelles.
+
Elle a été personnalisée pour appuyer la coordination des séances entre la plateforme d’acceptation et les FJI.
+
+
+
Version: 5.3
+
+
Site Web: https://www.gluu.org/ (en anglais)
+
+
Code source: https://github.com/sign-in-canada/gluu-passport/ (en anglais)
oxAuth est la composante principale de la plateforme d’acceptation, responsable de l’interface utilisateur et de la
+logique opérationnelle. En tant que fournisseuse OpenID Connect (en anglais), elle fournit
+également l’interface de programmation d’applications utilisée par les parties utilisatrices du gouvernement du Canada qui
+s’intègrent à l’aide d’OpenID Connect (en anglais).
+
+
Version: 4.4.0
+
+
Site Web: https://www.gluu.org/ (en anglais)
+
+
Code source: https://github.com/GluuFederation/oxAuth/ (en anglais)
+
+
Fournisseur d’identité SAML
+
+
Produit: Shibboleth IDP
+
+
Shibboleth est un fournisseur d’identité SAML (en anglais) qui fournit
+l’interface de programmation d’applications utilisée par les parties utilisatrices du gouvernement du Canada qui s’intègrent
+à l’aide de SAML (en anglais).
+
+
Version: 4.4.0
+
+
Site Web: https://www.shibboleth.net/products/identity-provider/ (en anglais)
+
+
Code source: https://wiki.shibboleth.net/confluence/display/DEV/Source+Code+Access/ (en anglais)
+
+
Base de données NoSQL
+
+
Produit: Couchbase Enterprise Server
+
+
Couchbase Server est un logiciel de base de données NoSQL en source libre, distribuée et multimodèle axée sur les documents
+qui est optimisé pour les applications interactives.
+
+
La plateforme Authenti-Canada utilise Couchbase pour stocker les profils d’utilisateurs et les configurations des parties
+utilisatrices, ainsi que pour la mise en cache répartie et à rendement élevé de séances.
L’équipe d’infrastructure du SCT effectuera un entretien du réseau qui pourrait entraîner une instabilité du service Authenti-Canada et une expérience incohérente pour l’utilisateur pendant une période de 10 minutes au cours de cette période.
Intégrez votre environnement de développement ou de tests
+
+
Que vous travailliez avec un service infonuagique ou que vous développiez votre propre application,
+vous pouvez intégrer vos environnements de non-production à L’Environnement d’essai pour l’acceptation
+des clients d’Authenti-Canada: Découvrez comment.
+ La plateforme Authenti-Canada fournit un service parapluie qui agit comme un intermédiaire de confiance
+ entre les fournisseurs de services d’identification et les programmes gouvernementaux qui les utilisent
+ pour fournir des services à leurs clients externes (par exemple, des particuliers, des entreprises et des représentants).
+
Voyez la plateforme Authenti-Canada en action. Essayez une démonstration en direct ou intégrez-la à votre propre environnement de développement ou de tests.
Êtes-vous prêt à utiliser la plateforme Authenti-Canada pour vos services en ligne destinés au public? Voici à quoi vous attendre.
+
+
Mobilisation initiale
+
+
La mobilisation se fera au moyen d’une série de réunions aux niveaux appropriés afin de donner un aperçu de la plateforme de service Authenti-Canada et des services de justificatifs d’identité appuyés, et de discuter des objectifs et de la portée de l’intégration du client et des échéanciers de haut niveau.
+
+
Examen et accord
+
+
Des réunions ou discussions seront organisées pour définir plus en détail les éléments suivants:
+
+
+
Portée
+
Calendrier et jalons
+
Coûts
+
Critères de succès
+
Résolution des problèmes
+
Disponibilité des ressources
+
+
+
Lorsque l’approbation pour continuer sera accordée, un document d’accord de collaboration sera signé.
+
+
Discussions techniques
+
+
Il s’agira d’une rencontre entre l’équipe d’intégration d’Authenti Canada et les ressources techniques du client.
+L’objectif principal de ces discussions est d’établir des points de contact, l’approche d’intégration et les attentes
+en matière de soutien.
+
+
Configuration technique de l’Environnement d’essai pour l’acceptation des clients (EEAC)
+
+
Le processus d’intégration technique standard est suivi pour tous les environnements de non-production du client.
+Les demandes de configuration sont gérées par l’équipe d’intégration avec le soutien du client, au besoin.
+
+
Processus de soutien aux utilisateurs finaux
+
+
L’équipe d’Authenti-Canada facilitera les réunions avec Services partagés Canada afin d’intégrer les processus de
+soutien des utilisateurs finaux du client à ceux des services de justificatifs d’identité applicables (CléGC, SCJ,
+deuxième facteur).
+
+
Migration des utilisateurs
+
+
Au besoin, l’équipe d’Authenti-Canada travaillera avec Services partagés Canada pour faciliter une migration harmonieuse
+des utilisateurs actuels de CléGC et du SCJ du client vers la plateforme d’Authenti-Canada.
+
+
Mise à l’essai et démonstration
+
+
À remplir par le client avec l’aide de l’équipe d’Authenti-Canada. Authenti-Canada fournira un soutien
+(dans la mesure du possible) à toutes les démonstrations auxquelles participent des publics externes ou de la direction.
+
+
Production
+
+
L’équipe d’Authenti-Canada et le client collaboreront pour promouvoir la solution pour la production.
+
+
Configuration technique de production
+
+
Le processus d’intégration technique standard sera suivi Les demandes de configuration seront gérées par
+l’équipe d’intégration avec le soutien du client, au besoin.
+
+
Activités de mise en service
+
+
À remplir par le client avec l’aide de l’équipe d’Authenti-Canada. Le client remplit un formulaire d’attestation
+de conformité de la Fédération d’Authenti-Canada pour attester que les évaluations de sécurité et de protection
+des renseignements personnels appropriées ont été effectuées, que les risques relevés ont été pris en compte et
+que la demande a obtenu l’autorisation d’exploiter appropriée.
+
+
Clôture de l’intégration de production
+
+
Critères de réussite remplis – production de rapports sur les résultats et clôture des activités d’intégration de la production.
+ 
+ 
+ 
+ 
+