Console Sign-In Through the Hub¶
Console sign-in through the Hub lets Connect on the Sites Dashboard open a site's console already signed in as the person's Hub user. The person needs no account and no password of their own at the site. Each site decides whether to allow it with the Console setting in its Hub Sign-In section, which is off by default.
When Connect Signs a Person In¶
Connect, or a double-click on the site's row, opens the site's Hub sign-in address instead of its console when all of these hold:
- The person's role holds the Console grant at the site, through one of the grant's tags (see Site Access Grants). Hub administrators need it too.
- The site's build takes console sign-ins from the Hub.
- The site has Use Hub and Console on.
- The site's Role Map has an entry for the person's Hub role (see Role Map).
Otherwise Connect opens the site's console as before, which shows the site's normal login page, or a session the browser already has at the site.
The Hub learns the site's build and Hub settings from the report the site sends when its tunnel connects, and again while the tunnel is up whenever the settings change (see Apply). Until a change reaches the Hub, Connect follows the last report, and the site still applies its current settings to every sign-in.
How the Sign-In Works¶
- The Hub signs a new console sign-in statement for the person and adds it to the request it sends to the site through the tunnel. The statement names the person, their Hub role and how they signed in to the Hub. The browser never holds it.
- The site answers its Hub sign-in address only for a request that came through its own Hub tunnel. Any other request, including one made straight to the site, gets 404 (Not Found).
- The site checks the statement: signed by its Hub, for this site, for a console sign-in, not expired and not used before. It then checks that Use Hub and Console are on and that it has not disabled the person's Hub user. Last, it checks that the Role Map maps the person's Hub role and that the person is within the site's request limits.
- The site creates or refreshes the person's Hub user, ends any session the browser already had at the site, starts a new one, and opens the console.
A statement stays valid for 60 seconds by default (qie.hubStatementExpirySeconds, set on the Hub), and the site accepts each one only once. The Hub signs a new one for every sign-in.
In the console the person has the permissions of the role the Role Map gives them. Changes they make show Hub Console in the Via column of revision history. A Hub user cannot lock the console. Logging out ends the site session and shows the site's login page.
The site's Enable two-factor authentication setting applies to password sign-ins at the site, not to a sign-in through the Hub. How strongly the person is identified is decided when they sign in to the Hub, as an identity provider decides it for an OIDC sign-in. The statement records how they signed in.
A Bookmarked Sign-In Address¶
The Hub sign-in address can be bookmarked or opened again later. Each time, the Hub checks the grants and the site's last report again and signs a new statement. When the sign-in is no longer allowed, or the Hub cannot sign a statement at that moment, the Hub sends the browser to the site's normal login page instead.
The Hub signs a person in only when Connect or the person started the sign-in. Connect adds a one-time code to the address, and the browser marks an address the person typed or opened from a bookmark as opened by the person. When a page opens the address instead, such as another site's page in the same browser, the Hub sends the browser to the site's normal login page and signs nothing.
As for any page through the proxy, the person must be signed in to the Hub and their role must hold Console at the site, whether or not they are a Hub administrator.
When the Site Refuses¶
Every refused sign-in sends the browser to the site's normal login page, with no message about why. The site records the refusal with its reason. A refusal that the site's own settings explain, such as Console turned off since the site's last report or a Hub user the site disabled, raises no alert. A statement that looks forged, replayed or misdirected raises an admin alert at the site (see Limits, Records and Alerts).
What Is Recorded¶
At the site:
- The statement, accepted or refused, kept for the MCP page's Audit Retention (days).
- The sign-in, in
access.logandqie.logas for any console sign-in, with the browser's address as the Hub resolved it. The Hub user's Last Login is updated. - With the Log Level at INFO, DEBUG or TRACE,
qie.logalso names the Hub user and the id of the statement that signed them in. - Changes made during the session, in revision history with Via Hub Console.
At the Hub, the statement goes into the Hub's own statement record, kept for Statement Retention (days) on the Hub Configuration page, and into a STATEMENT_SIGNED line in hub-audit.log.
When the Hub Ends a Person's Console Sessions¶
The Hub ends a person's Hub console sessions at sites when the person loses access at the Hub:
| What happens at the Hub | Sites where the sessions end |
|---|---|
| A Hub session that opened a site through the proxy ends: the person signs out of the Hub, or the session times out | Every site where the person signed in through the Hub |
| The person's Hub account is disabled | Every site where the person signed in through the Hub |
| The person's Hub account is deleted | Every site where the person signed in through the Hub |
| The person is given another role | Every site where the person signed in through the Hub, because a site gives the person the role their Hub role maps to only when they sign in |
| The person's role is renamed, other than a change of case or surrounding spaces | Every site where the person signed in through the Hub, because a site's Role Map names Hub roles and maps the name only when the person signs in |
| A Console grant is taken off the person's role, a tag is taken off a site, or a tag is deleted | The affected sites where the person signed in through the Hub and the Hub would no longer sign them in |
Taking away a Jobs or MCP grant ends no site session. A configuration import at the Hub that gives a person another role, or renames their role, ends their sessions the same way.
The Hub finds the sites where a person signed in from the console sign-in statements it keeps. When Statement Retention (days) is set, a site whose last console sign-in statement for the person has been purged is not reached.
How the Request Reaches the Site¶
The Hub keeps one queued request for each site and person, holding the latest time of a change. The Hub node that holds the site's tunnel sends it: right after the change when that node made it, whenever the site's tunnel connects, and every 30 seconds until the site acknowledges it. A site that is offline gets the request when it reconnects. Lockdowns never hold a request back. Deleting a site deletes its queued requests.
At the site, the request sets a time on the person's Hub user before which their Hub console sessions are no longer valid. The time only moves forward, and never past the site's own clock. Each session that started earlier ends on its next request, and the browser goes to the site's login page. The site does not disable the Hub user, so the person can sign in through the Hub again once they regain access. A person with no Hub user at the site has nothing to end, and the site acknowledges the request at once.
The site also ends a Hub console session on its next request when a site administrator disables or deletes the Hub user, turns off Use Hub or Console, or changes the Role Map so that the Hub role the person signed in with no longer maps to the role their Hub user holds.
A Hub console session works only through the Hub. A request in the session that reaches the site's own address instead, for example with the session's cookie copied out of the browser, ends the session.
Older Sites¶
- A site whose build does not take console sign-ins from the Hub: Connect opens its console as before. The same applies to a site that has not reported its Hub settings since the Hub was upgraded.
- A site whose build does not end sessions on request: The Hub keeps its requests queued and sends them once the site connects with a build that does.