docs(15.9): SSO authentication moved to fess-sso-* plugins

[marevol]

Stacked on #528 and targets its branch, because both add a section to the same install/upgrade.rst. Merge #528 first; GitHub retargets this to master when it does — worth confirming afterwards that the commit actually reached master. Content-wise this belongs after codelibs/fess#3430, and the four plugins have to be published before anyone follows the instructions here.

All four authenticators left the distribution in codelibs/fess#3430, so each sso.type value comes from its own plugin. 42 files, all seven languages, 15.9 development trees only.

sso.type	plugin
saml	fess-sso-saml
spnego	fess-sso-spnego
entraid, and the legacy aad	fess-sso-entraid
oic	fess-sso-oidc

That last pair is the one place the plugin name and the sso.type value differ, so the upgrade section and the sso-oidc note both say it outright rather than leaving a reader to install fess-sso-oic.

One section, not four. The mapping is the point, and four near-identical sections would triple the page. It sits after the S3 section so the three "moved to a plugin" changes read together, and the GCS section's "see the next section" still lands on S3. Every hunk in each upgrade.rst is a pure insertion — the S3 and GCS sections are byte-for-byte untouched.

What the section says

• What survives: sso.type and the saml.*, spnego.*, entraid.*, aad.* and oic.* keys live in WEB-INF/conf/system.properties.
• What does not change: the General screen still offers all four types and still shows their settings, because a plugin cannot supply a JSP, so nothing on that screen reports a missing plugin.
• The symptom, taken from the code rather than from my summary of it. With the plugin absent, SsoAction.index() calls saveError(errors.sso_login_error) before redirecting, so the login page does say "SSO login process failed." — a message that names neither the cause nor the remedy. 15.9 adds the warning in fess.log naming the component and the plugin; up to 15.8 there was only a debug line.

Every claim was checked against refs/remotes/pr/3430 rather than master, since master still has the authenticators in core. FessProp.java and admin_general.jsp are not in that PR's diff at all, which is what makes the two "unchanged" statements above safe to print.

Also: 28 notes at the end of each config/sso-*.rst Overview — the same relationship the storage-guide note has to the settings it qualifies — and 28 general-guide.rst option rows taking the (requires the X plugin) suffix already used there for the storage types.

Deliberately absent

No size figure. The adjacent GCS and S3 sections give none; adding one only here would make this look like the largest of the three.

The woodstox / StAX side effect is not here. woodstox-core and stax2-api leave with java-saml, and XMLInputFactory falls back to the JDK provider. That asks nothing of the reader — the JDK implementation is complete, and no remaining runtime artifact registers a javax.xml.stream provider, so there is one answer regardless of which plugins are installed. Every section in this block ends by telling an admin what to do; this one would manufacture a work item that does not exist. It is recorded in #3430. A third-party plugin importing com.ctc.wstx or org.codehaus.stax2 would now fail, which belongs in release notes or dev/plugin-architecture.rst rather than an upgrade checklist, and is unverified for any code outside this workspace.

api/admin/api-admin-general.rst unchanged. It documents ssoType with its five values. #528 did not annotate storageType in the same table, so annotating ssoType alone would make the two inconsistent — both rows or neither.

Wording

Taken from each tree, not translated afresh: the heading frame and the "no longer part of the distribution / comes from the X plugin" sentence from the GCS and S3 sections, the install phrasing and the system.properties sentence from S3, the admin-screen reference from the SPNEGO migration section further down the same file, the .. note:: frame from the storage-guide note, and the (requires …) suffix from general-guide's storage rows.

Two house styles were found by comparing rather than assuming: config/sso-*.rst spells the term without a space (SAML認証, Windows集成认证, 10:1 and 9:1 against the spaced form) where install/upgrade.rst spells it with one, and ko puts the comma tight against a literal's end-string.

Korean particles. 은/는 and 을/를 agree with the Korean reading of the preceding token, which saml, spnego and oic do not have — so spnego는 is wrong whichever form is chosen. The ko section is structured so no such particle ever follows a Latin code literal, which is how the existing ko tree already avoids it.

Verification

docutils 0.22.4 across the 42 files, before and after, parsed the way Sphinx parses. 301 assertions, 0 failures, with the expected deltas declared before the run.

• System messages identical per file, as counters with path:lineno: prefixes stripped — insertions shift every later line, so a raw diff would be useless.
• No new unparsed markup; the one pre-existing residue per upgrade.rst (the **bold**/|Fess| defect at en:345) unchanged.
• One document-level section per file; total sections +1 on exactly the seven upgrade.rst, +0 on the other 35, each added node printed by name.
• All 266 new inline literals parse as literal nodes — the check for a start-string against a CJK character.
• Notes +1 on exactly the 28 config/sso-*.rst, +0 elsewhere, which is what catches a mis-indented note body.
• Heading rules match their titles by display width (de 55, en 35, es 35, fr 45, ja 26, ko 28, zh-cn 16); ko is padded, since Hangul is W.

Non-vacuity, 51 assertions across two scripts, both green. docutils 0.22.4's real behaviour was established first, and two of the initial assertions were wrong rather than the harness: fullwidth punctuation after an end-string is accepted (so the \ ， escapes in the zh-cn tree are house style, not a requirement), while a CJK character directly before a start-string is dropped with no system message at all — only the literal-node and residue checks see it.

Proven in both directions: synthetic controls for ja/ko/zh in both adjacency directions, note bodies indented and not, heading rules short and correct; then the real edited files mutated — jamming a word character against WEB-INF/conf/system.properties in each of the seven upgrade.rst drops its literal nodes 2 → 0 and raises residue 1 → 5; and finally the whole harness run against four deliberate mutations of the ja file (jammed literal, short rule, deleted section, unindented note), red all four times, green again after restoring the file byte-identical by sha256.

One figure still needs measuring

install/upgrade.rst says the ZIP drops from 438.5 MiB to 204.7 MiB, in the Node.js section. The GCS change updated that number (218.9 → 204.7) with a measured compressed delta, so updating it is the established convention here — but the S3 change did not, and neither does this one. It cannot be derived: #3430's 5,827,073 is uncompressed jar bytes, not archive entries, and no built distribution is available to weigh. Recommend one measured update covering S3 and SSO together before release.