Option A ? Option B Migration Guide

When to migrate, what breaks, and minimal steps. Based on YHPro analysis.

Comparison at a glance

Item	Option B (current YHPro)	Option A (target)
IDM redirect_uri	`.../shr/api/oAToSHR`	`.../shr`
OAuth callback	Servlet `callBack()`	`/shr?code=` �� ValidationFilter
Session	LtpaToken + index2sso.jsp	`_const_cas_assertion_`
Portal JS	�� OAToSHR?service=	�� SHR URL direct or /shr?adsso
Deep link	OAuth state (dynamic)	state or urlToMap (dynamic)
Config file	OASSOConfig.properties	adSsoConfig.properties
Logout	SHRToIDMLogout + logoutHR.js	Platform logout + IDM extension
CAS UrlPattern	Excludes servlet, index2sso	Standard filter chain

B �� A migration

Prerequisites

IDM admin can register new redirect_uri (https://{host}/shr)
Dev/test environment for parallel validation
User mapping unchanged (cfidmusercode)

Steps

Phase 1 �� Build Option A
  [ ] IdmCodeValidata (port SsoUtil.getAccessToken + checkUserExist)
  [ ] KDPortalAuthenticationFilter (IDM authorize + state/urlToMap)
  [ ] KDPortalTicketValidationFilter (code �� IdmCodeValidata)
  [ ] ConfigAddressUtil + adSsoConfig.properties
  [ ] Overlay deploy to shr_web.war/WEB-INF/classes
  [ ] Protocol.YH patch if needed (code, redirect_uri)

Phase 2 �� IDM
  [ ] Register redirect_uri = https://{host}/shr
  [ ] Keep servlet redirect_uri during transition (optional)

Phase 3 �� Portal
  [ ] login_withForm.js: replace OAToSHR redirect with location.replace(serviceParam)
  [ ] Or portal menus �� direct SHR links
  [ ] Remove hardcoded ENV_CONFIG from JS; inject from server
  [ ] Keep /shr/home.do whitelist (move to Filter flag)

Phase 4 �� Validate
  [ ] Portal todo deep link
  [ ] Direct /shr access without session
  [ ] /shr/home.do local login
  [ ] Session has _const_cas_assertion_
  [ ] Logout clears SHR + IDM

Phase 5 �� Decommission B
  [ ] Remove OAToSHR servlet from web.xml (or deprecate)
  [ ] Remove servlet paths from UrlPattern if unused
  [ ] Remove IDM servlet redirect_uri
  [ ] Archive OASSOConfig or merge into adSsoConfig

Rollback

Keep OAToSHR servlet and dual redirect_uri in IDM until Option A verified. Portal JS switch is one flag:

mode: "servlet"  // �� OAToSHR
mode: "direct"   // �� Option A

A �� B migration

Use when servlet/Ltpa approach required (e.g. IDM mandates servlet callback, or federated logout JSON already built).

  [ ] Implement OAToSHR + SsoUtil + SHRToIDMLogout
  [ ] OASSOConfig.properties
  [ ] web.xml servlet mappings
  [ ] ssoParamemter.properties: exclude /api/oAToSHR, /index2sso.jsp
  [ ] IDM redirect_uri �� servlet URL
  [ ] login_withForm.js �� OAToSHR bridge
  [ ] logoutHR.js �� SHRToIDMLogout JSON
  [ ] Revert or disable Filter overlay classes

What not to do

Mistake	Why
Run OAToSHR + Filter overlay on same user journey	Two session models (Ltpa vs assertion)
Same redirect_uri for /shr and /api/oAToSHR	IDM allows multiple URIs but each OAuth flow must be consistent
Keep login_withForm �� OAToSHR after Option A active	Double redirect; wrong callback
Hardcode URLs in JS during migration	Use server-injected config + mode flag
Delete OASSOConfig before adSsoConfig validated	Config field names differ

Config migration table

Copy values when moving B �� A:

OASSOConfig	adSsoConfig
authorizePath	authUrl
getAccessTokenPath	tokenUrl
client_id	client_id
client_secret	client_secret
serverName + `/shr`	shrUrl
idmBaseUrl	idmBaseUrl (logout)
ssoUrl	do not copy �� A uses shrUrl as redirect_uri

YHPro WIP filter code

com.kingdee.eas.custom.sso.filter.PortalAuthenticationFilter was an abandoned Option A attempt:

Hardcoded shr-test.iyuhu.com/api/oAToSHR
Not in web.xml
POST token API unlike production OAToSHR GET

Do not enable as-is. Port useful ideas into proper com.kingdee.bos.sso.client overlay per idm-filter-reference.md.

Decision: migrate or stay?

Stay Option B	Migrate to Option A
Production stable	Want platform-native SHR session
IDM redirect_uri fixed on servlet	Can change IDM to /shr callback
Team familiar with OAToSHR	Reducing eassso JS hack long-term
Short timeline	Willing to invest Filter overlay + regression

Option B with proper engineering (src overlay, server config injection, unified logout servlet) is valid long-term if Option A cost outweighs benefit.

migration-guide.md 4.7 KB Geschiedenis Ruwe