- Published on
Symantec SiteMinder 아키텍처 해부 — 레거시 엔터프라이즈 WebSSO의 표준
- Authors
- Name
- Youngju Kim
- @fjvbn20031
- 들어가며 — 2026년에 왜 SiteMinder를 이야기하나
- SiteMinder의 역사 — Netegrity에서 Broadcom까지
- 전체 아키텍처 개요
- SMSESSION 쿠키와 세션 모델
- 정책 객체 모델 — realm, rule, policy, response
- 인증 스킴 (Authentication Schemes)
- 요청 처리 흐름 — Agent는 어떻게 가로채나
- HTTP 헤더 기반 사용자 전달 — SM_USER와 보안 함의
- Federation — SAML로 바깥 세상과 연결
- 12.9 현황과 컨테이너화 흐름
- 왜 아직도 금융권과 대기업에 남아 있나
- 운영 관점 체크리스트 — SiteMinder 환경을 물려받았다면
- 안티패턴 모음
- 마치며
- 참고 자료
들어가며 — 2026년에 왜 SiteMinder를 이야기하나
2026년의 IAM 트렌드는 분명합니다. passkeys가 로그인의 기본값이 되어가고 있고, Keycloak 26.6은 FAPI 2.0 Final 지원과 MCP(Model Context Protocol) 인가 서버 역할까지 품었으며, AI 에이전트 같은 non-human identity 관리가 새로운 화두입니다. 그런데 이 글은 거꾸로 20년도 더 된 기술, Symantec SiteMinder(사이트마인더)를 다룹니다.
이유는 간단합니다. 아직도 전 세계 금융권과 대기업의 인트라넷 깊숙한 곳에서 SiteMinder가 수백, 수천 개의 애플리케이션을 보호하고 있기 때문입니다. 모던 IAM으로의 전환 프로젝트는 거의 예외 없이 "기존 SiteMinder 환경을 어떻게 할 것인가"라는 질문에서 시작합니다. 레거시를 모르면 마이그레이션 설계도 할 수 없습니다.
이 글에서는 SiteMinder의 역사, 핵심 컴포넌트, 세션 모델, 정책 객체 모델, 요청 처리 흐름, 그리고 헤더 기반 인증의 보안 함의까지 아키텍처 관점에서 깊이 있게 해부합니다. 후속 글에서 다룰 Keycloak 마이그레이션 전략과 하이브리드 공존 패턴의 기초가 되는 내용입니다.
SiteMinder의 역사 — Netegrity에서 Broadcom까지
SiteMinder의 소유권 변천사는 그 자체로 엔터프라이즈 소프트웨어 산업의 역사입니다.
| 시기 | 소유 회사 | 비고 |
|---|---|---|
| 1995~2004 | Netegrity | WebSSO 개념을 사실상 정립한 원조 제품 |
| 2004~2018 | CA Technologies | CA SSO / CA Single Sign-On으로 리브랜딩 |
| 2018~현재 | Broadcom (Symantec 브랜드) | Symantec SiteMinder로 재명명, 12.8/12.9 라인 유지 |
1990년대 후반, 웹 애플리케이션이 폭발적으로 늘어나면서 "앱마다 따로 로그인"하는 문제가 대두됐습니다. Netegrity는 중앙 정책 서버 + 웹 서버에 심는 에이전트 조합으로 이 문제를 풀었고, 이 아키텍처는 이후 Oracle Access Manager, IBM Tivoli Access Manager(현 IBM Verify Access), Ping Access 등 모든 WebSSO 제품의 원형이 되었습니다.
2026년 현재 기준으로 중요한 사실 몇 가지를 짚으면 다음과 같습니다.
- 최신 메이저 버전은 12.9이며, Broadcom Tech Docs에서 문서를 제공합니다.
- 12.8.04는 2023년 12월에 EOS(End of Service)를 맞았습니다. 구버전을 쓰는 조직은 지원 공백 리스크에 노출되어 있습니다.
- Broadcom은 Policy Server와 Access Gateway의 쿠버네티스 컨테이너 배포를 지원하며 현대화 흐름에 대응하고 있습니다.
- 그럼에도 라이선스 비용, 폐쇄적 생태계, 표준 프로토콜 중심 설계가 아니라는 점 때문에 많은 조직이 Keycloak 등으로의 전환을 검토하고 있습니다.
전체 아키텍처 개요
SiteMinder의 아키텍처는 크게 다섯 가지 컴포넌트로 구성됩니다.
+---------------------------+
| Admin UI |
| (정책 관리 콘솔, WAMUI) |
+------------+--------------+
| 관리/설정
v
+----------------+ TCP 44441-3 +---------------------------+
| Web Agent | <-----------> | Policy Server |
| (웹서버 모듈) | (Agent API) | - 인증(IsAuthenticated) |
+-------+--------+ | - 인가(IsAuthorized) |
| | - 세션/감사/키 관리 |
| 보호 +------+-------------+------+
v | |
+----------------+ +-------v-----+ +-----v--------+
| 보호 대상 앱 | | Policy Store| | Session Store|
| (인트라넷 웹앱) | | (LDAP/RDBMS)| | (RDBMS 등) |
+----------------+ +-------------+ +--------------+
|
+-------v--------+
| User Store |
| (AD/LDAP/RDBMS)|
+----------------+
Policy Server — 두뇌
Policy Server는 SiteMinder의 핵심 의사결정 엔진입니다. 역할은 다음과 같습니다.
- 인증 결정: 사용자가 제시한 크리덴셜(폼, 인증서, Kerberos 등)을 User Store와 대조해 검증합니다.
- 인가 결정: 인증된 사용자가 특정 리소스에 접근할 수 있는지 정책을 평가합니다.
- 세션 관리: 세션 티켓 발급, 유효성 검증, idle/max timeout 적용.
- 키 관리: SMSESSION 쿠키를 암호화하는 Agent Key의 생성과 롤오버.
- 감사 로깅: 인증/인가 이벤트를 감사 저장소에 기록.
Policy Server는 보통 TCP 44441(계정), 44442(인증), 44443(인가) 포트로 Web Agent와 통신했으며, 최신 버전에서는 단일 포트로 다중화됩니다. 고가용성을 위해 여러 대를 클러스터로 묶고 Agent가 페일오버하도록 구성하는 것이 표준 토폴로지입니다.
Web Agent — 손과 발
Web Agent는 Apache, IIS, Nginx(Access Gateway 경유) 등 웹 서버에 설치되는 인프로세스 모듈입니다. 모든 HTTP 요청을 가로채서 다음을 수행합니다.
- 요청 URL이 보호 대상인지 Policy Server에 질의 (IsProtected)
- 보호 대상이면 SMSESSION 쿠키 존재/유효성 확인
- 쿠키가 없거나 무효이면 인증 스킴에 따라 로그인 페이지로 리다이렉트
- 인증/인가 성공 시 사용자 정보를 HTTP 헤더에 실어 백엔드 앱으로 전달
Agent는 성능을 위해 정책 결정을 로컬 캐시합니다. Agent Cache의 TTL 설정은 보안(정책 변경 즉시 반영)과 성능(Policy Server 부하) 사이의 트레이드오프입니다.
Policy Store — 정책의 저장소
realm, rule, policy, response 등 모든 정책 객체가 저장되는 곳입니다. 전통적으로 LDAP 디렉터리(CA Directory 등)를 썼고 RDBMS도 지원합니다. Policy Store는 모든 Policy Server가 공유하는 단일 진실 공급원(single source of truth)입니다.
Session Store — 서버 사이드 세션 (선택적)
SiteMinder 세션은 기본적으로 쿠키 안에 모든 것이 들어 있는 stateless 모델입니다. 그러나 다음 기능을 쓰려면 서버 사이드 Session Store가 필요합니다.
- 관리자에 의한 강제 세션 종료(session revocation)
- 동시 세션 수 제한
- SAML 페더레이션의 아티팩트/세션 상태 저장
Admin UI — 관리 콘솔
WAMUI(Web Access Management UI)라 불리는 웹 기반 관리 콘솔로, 정책 객체의 생성/수정과 Agent 설정을 담당합니다. 대규모 환경에서는 Perl/Java 기반의 Policy Management API로 정책을 코드로 관리하기도 합니다.
SMSESSION 쿠키와 세션 모델
SiteMinder SSO의 심장은 SMSESSION 쿠키입니다.
GET /portal/dashboard HTTP/1.1
Host: intranet.example.com
Cookie: SMSESSION=Av3qB9x...암호화된 세션 티켓...K2w=
동작 원리를 정리하면 다음과 같습니다.
- 사용자가 최초 인증에 성공하면 Policy Server가 세션 티켓(session spec)을 생성합니다. 티켓에는 사용자 DN, 인증 시각, 인증 레벨, idle/max timeout 정보가 들어 있습니다.
- 티켓은 Policy Server가 관리하는 대칭키(Agent Key) 로 암호화되어 SMSESSION 쿠키로 브라우저에 내려갑니다.
- 같은 쿠키 도메인(예: .example.com) 안의 다른 앱에 접근하면, 그 앱의 Web Agent가 쿠키를 Policy Server에 보내 복호화/검증하고 — 유효하면 재로그인 없이 통과시킵니다. 이것이 SSO의 실체입니다.
- Agent Key는 주기적으로 롤오버됩니다. Policy Server는 현재 키와 이전 키를 함께 유지해 롤오버 중에도 기존 쿠키를 검증할 수 있게 합니다.
이 모델의 특성을 모던 토큰 기반(OIDC) 모델과 비교하면 다음과 같습니다.
| 항목 | SiteMinder SMSESSION | OIDC (Keycloak 등) |
|---|---|---|
| 토큰 형식 | 독점 암호화 바이너리 쿠키 | 표준 JWT (서명 기반) |
| 검증 방식 | Agent가 Policy Server에 질의 | 클라이언트가 서명 자체 검증 가능 |
| SSO 범위 | 쿠키 도메인 단위 | IdP 세션 + 리다이렉트 기반, 도메인 무관 |
| 세션 해지 | Session Store 사용 시 가능 | 토큰 수명 + back-channel logout |
| 표준성 | 비표준 (벤더 종속) | IETF/OpenID 표준 |
| API/모바일 | 부적합 (브라우저 쿠키 전제) | 적합 (Bearer 토큰) |
쿠키 도메인 단위 SSO라는 점이 중요합니다. 다른 도메인 간 SSO가 필요하면 SiteMinder는 별도의 페더레이션 기능(SAML)이나 쿠키 프로바이더 구성을 동원해야 합니다.
정책 객체 모델 — realm, rule, policy, response
SiteMinder의 인가 모델을 이해하려면 네 가지 객체를 알아야 합니다. 이 객체 모델은 마이그레이션 시 Keycloak 개념으로 매핑해야 하는 대상이기도 합니다.
Domain (정책 도메인)
├── Realm: 보호할 리소스 영역 (URL prefix + 인증 스킴)
│ 예) Agent=intranet-agent, Resource=/hr/*
│ AuthScheme=Forms, SessionTimeout=30m
│
├── Rule: realm 안에서의 행위 매칭
│ 예) GET,POST on /hr/payroll/* (Web Agent action)
│ OnAuthAccept 이벤트 룰
│
├── Policy: Rule + 사용자(그룹/DN 필터) 바인딩
│ 예) "HR-Payroll-Access" =
│ Rule(/hr/payroll/*) + LDAP group cn=hr-staff
│
└── Response: 정책 매칭 시 부가 동작
예) HTTP 헤더 SM_USER, SM_USERGROUPS 주입,
리다이렉트, 쿠키 설정
각 객체를 좀 더 자세히 보겠습니다.
Realm
보호 대상 리소스의 묶음입니다. 특정 Agent(또는 Agent 그룹)와 리소스 필터(URL prefix), 그리고 인증 스킴을 연결합니다. realm 단위로 세션 idle/max timeout, 인증 레벨(protection level)을 지정합니다. "이 URL 영역은 폼 인증으로 보호하고 세션은 30분"이라는 선언이 realm입니다.
Rule
realm 내부에서 구체적인 리소스 패턴과 HTTP 액션(GET, POST, PUT 등)을 매칭합니다. Web Agent action 외에도 OnAuthAccept, OnAuthReject, OnAccessAccept 같은 이벤트 룰이 있어 인증 성공/실패 시점에 response를 발동시킬 수 있습니다.
Policy
rule과 사용자 집합을 묶는 객체입니다. 사용자 집합은 LDAP 그룹, 조직 단위(OU), DN 필터, 동적 표현식으로 정의합니다. 시간 제약(평일 09-18시만 허용)이나 IP 제약도 policy에 걸 수 있습니다.
Response
정책이 매칭되었을 때 Web Agent에게 내려보내는 지시입니다. 가장 흔한 용도가 HTTP 헤더 주입입니다. 백엔드 앱은 이 헤더를 읽어 "누가 로그인했는지"를 알게 됩니다. 이 메커니즘이 SiteMinder 생태계의 축복이자 저주인데, 뒤에서 자세히 다룹니다.
인증 스킴 (Authentication Schemes)
realm마다 지정하는 인증 스킴은 매우 다양합니다. 대표적인 것들을 정리합니다.
| 스킴 | 설명 | 사용 사례 |
|---|---|---|
| Basic | HTTP Basic 인증 | 레거시 내부 도구, API성 호출 |
| HTML Forms (FCC) | .fcc 파일 기반 커스텀 로그인 폼 | 가장 일반적인 직원 포털 로그인 |
| X.509 Certificate | 클라이언트 인증서 (mTLS) | 고보안 금융 업무 |
| Windows Authentication | Kerberos/NTLM 통합 인증 | AD 환경 데스크톱 SSO |
| SAML 2.0 | 페더레이션 파트너로부터의 assertion | 외부 IdP 연동 |
| RADIUS / OTP | 2차 인증 결합 | step-up 인증 |
| Custom (SDK) | Java/C SDK로 작성한 커스텀 스킴 | 사내 고유 인증 체계 |
특기할 점은 protection level 개념입니다. 스킴마다 1~1000의 보호 레벨을 부여하고, 사용자가 낮은 레벨 스킴으로 인증한 상태에서 높은 레벨 realm에 접근하면 재인증(step-up)을 요구합니다. 모던 IAM의 ACR/AMR, step-up authentication 개념의 조상 격입니다.
FCC(Forms Credential Collector) 파일은 다음과 같은 독특한 형식의 템플릿입니다.
@username=%USER%
@smretries=2
<html>
<body>
<form name="login" method="post">
<input type="text" name="USER">
<input type="password" name="PASSWORD">
<input type="hidden" name="target" value="%TARGET%">
<input type="submit" value="Login">
</form>
</body>
</html>
login.fcc 커스터마이징은 수많은 SiteMinder 운영자의 손때가 묻은 영역으로, 마이그레이션 시 Keycloak 로그인 테마로 다시 구현해야 하는 부분입니다.
요청 처리 흐름 — Agent는 어떻게 가로채나
전체 흐름을 단계별로 따라가 보겠습니다. 미인증 사용자가 보호 리소스에 접근하는 시나리오입니다.
브라우저 Web Agent Policy Server User Store
| | | |
|--1 GET /hr/----->| | |
| |--2 IsProtected?---->| |
| |<--Yes, Forms scheme-| |
| | (3) SMSESSION 없음 | |
|<-4 302 login.fcc-| | |
| ?TARGET=/hr/ | | |
| | | |
|--5 POST 자격증명->| | |
| |--6 Login(user,pw)-->|--7 LDAP bind---->|
| | |<--OK-------------|
| |<-8 세션티켓+Response--| |
|<-9 Set-Cookie:--| | |
| SMSESSION=... | | |
| 302 /hr/ | | |
| | | |
|--10 GET /hr/---->| | |
| (SMSESSION 포함)|--11 Validate+------>| |
| | IsAuthorized? | |
| |<--OK + 헤더 지시-----| |
| | (12) SM_USER 등 | |
| | 헤더 주입 후 앱 호출 | |
|<-13 200 OK------| | |
핵심 단계를 짚으면 다음과 같습니다.
- IsProtected: Agent가 URL이 어떤 realm에 속하는지, 어떤 인증 스킴이 필요한지 질의합니다. 결과는 Agent에 캐시됩니다.
- Credential Collection: Forms 스킴이면 login.fcc로 리다이렉트하고, 원래 가려던 URL은 TARGET 파라미터로 보존합니다.
- 인증과 세션 발급: Policy Server가 User Store(주로 AD/LDAP)에 bind를 시도해 검증하고, 성공하면 세션 티켓을 만들어 암호화한 뒤 SMSESSION 쿠키로 내려보냅니다.
- 인가와 헤더 주입: 이후 요청마다(캐시 TTL 내에서는 캐시로) IsAuthorized를 평가하고, 매칭된 policy의 response에 따라 HTTP 헤더를 주입해 백엔드로 전달합니다.
같은 쿠키 도메인의 두 번째 앱에 접근하면 4~9단계가 생략되고 SMSESSION 검증만으로 통과합니다. 사용자 입장에서 "한 번 로그인으로 모든 인트라넷 앱 접근"이 실현되는 것입니다.
HTTP 헤더 기반 사용자 전달 — SM_USER와 보안 함의
SiteMinder 보호 하의 백엔드 앱이 받는 요청은 대략 이렇습니다.
GET /hr/payroll/list HTTP/1.1
Host: hr-app.internal.example.com
SM_USER: jdoe
SM_USERDN: uid=jdoe,ou=people,dc=example,dc=com
SM_USERGROUPS: hr-staff^payroll-admin
SM_SESSIONID: aBcD1234...
SM_AUTHTYPE: Forms
X-Custom-Empno: 100234
앱은 인증 로직 없이 SM_USER 헤더만 읽으면 됩니다. Java 서블릿이라면 다음과 같은 코드가 전형적입니다.
// 레거시 앱의 전형적인 SiteMinder 연동 코드
public class SmUserFilter implements Filter {
@Override
public void doFilter(ServletRequest req, ServletResponse res,
FilterChain chain) throws IOException, ServletException {
HttpServletRequest request = (HttpServletRequest) req;
String user = request.getHeader("SM_USER");
if (user == null || user.isEmpty()) {
((HttpServletResponse) res).sendError(401, "No SSO context");
return;
}
// 헤더 값을 그대로 신뢰하여 보안 컨텍스트 구성
SecurityContextHolder.setPrincipal(new SmPrincipal(user));
chain.doFilter(req, res);
}
}
이 패턴은 앱 개발을 극도로 단순하게 만들어 주었고, 그래서 수천 개의 사내 앱이 이렇게 작성되었습니다. 그러나 심각한 보안 전제가 숨어 있습니다.
Header Injection 공격 표면
앱이 헤더를 무조건 신뢰한다는 것은, Web Agent를 우회해 앱에 직접 도달할 수 있는 경로가 하나라도 있으면 즉시 인증 우회가 된다는 뜻입니다.
# Agent를 우회해 앱 서버에 직접 접근 가능한 네트워크라면
# 공격자가 헤더를 위조하는 데 curl 한 줄이면 충분합니다
curl -H "SM_USER: ceo" -H "SM_USERGROUPS: payroll-admin" \
http://hr-app.internal.example.com:8080/hr/payroll/list
따라서 헤더 기반 아키텍처에서는 다음이 필수입니다.
- 네트워크 격리: 앱 서버는 오직 Agent가 설치된 웹 서버/게이트웨이에서만 접근 가능해야 합니다(방화벽, 보안 그룹).
- 헤더 스트리핑: Agent/프록시는 외부에서 들어온 SM_USER 류 헤더를 반드시 제거한 뒤 자체 값으로 덮어써야 합니다.
- 상호 인증: 가능하다면 게이트웨이와 앱 사이에 mTLS 또는 공유 시크릿 헤더를 추가해 출처를 검증합니다.
이 보안 함의는 마이그레이션 후에도 그대로 따라옵니다. oauth2-proxy 같은 모던 프록시로 헤더 주입 패턴을 재현할 때도 동일한 격리 원칙을 지켜야 합니다. 자세한 내용은 OWASP의 인증 관련 가이드도 참고할 만합니다.
헤더 인코딩 함정
운영하다 보면 만나는 고전적인 함정도 있습니다.
- SM_USERGROUPS의 구분자가 캐럿(^)이라 파싱 코드가 콤마를 가정하면 깨집니다.
- 한글 등 비ASCII 사용자 속성이 RFC 2047 인코딩으로 내려와 앱이 깨진 문자열을 받는 경우가 있습니다.
- Agent 설정의 LegacyVariables 여부에 따라 헤더 이름이 SM_USER인지 SMUSER인지 달라집니다 — 마이그레이션 인벤토리 조사 때 반드시 확인해야 할 항목입니다.
Federation — SAML로 바깥 세상과 연결
SiteMinder는 순수 WebSSO 외에 페더레이션 기능도 갖추고 있습니다. Federation Partnership 구성으로 SiteMinder를 SAML 2.0 IdP 또는 SP로 동작시킬 수 있습니다.
- IdP로서: SMSESSION을 가진 사용자에 대해 SAML assertion을 발급해 외부 SaaS(Salesforce 등)나 파트너에 SSO를 제공합니다.
- SP로서: 외부 IdP가 발급한 assertion을 받아 SMSESSION으로 변환합니다. 이 방향이 마이그레이션 공존 설계에서 결정적으로 중요합니다 — Keycloak을 IdP로, SiteMinder를 SP로 두면 모던 스택에서 로그인한 사용자가 레거시 앱 영역으로 끊김 없이 넘어갈 수 있기 때문입니다.
- OIDC 지원도 후기 버전에 추가되었지만, SAML에 비해 기능 폭이 좁고 현장 채택도 제한적입니다.
페더레이션 기능을 쓰려면 Session Store가 사실상 필수이고, 인증서/메타데이터 관리 부담이 더해집니다.
12.9 현황과 컨테이너화 흐름
Broadcom은 SiteMinder를 버리지 않았습니다. 12.9 라인에서의 변화는 다음과 같습니다.
- 컨테이너 배포: Policy Server, Access Gateway, Admin UI의 도커 이미지와 쿠버네티스 헬름 차트가 제공되어, VM 기반 수동 설치 대신 선언적 배포가 가능해졌습니다.
- Access Gateway 중심 전환: 개별 웹 서버마다 Agent를 심는 대신, 중앙 리버스 프록시형 게이트웨이(Access Gateway, 구 Secure Proxy Server)로 보호를 모으는 패턴이 권장됩니다. 이는 흥미롭게도 모던 아키텍처의 게이트웨이 패턴과 수렴하는 방향입니다.
- REST API 확충: 정책 관리용 REST API가 보강되어 IaC성 자동화가 가능해졌습니다.
그러나 본질적 한계는 남습니다. SMSESSION은 여전히 비표준이고, 라이선스는 여전히 비싸며, 신규 인력이 배우려 하지 않는 기술 스택이라는 점입니다.
왜 아직도 금융권과 대기업에 남아 있나
기술적으로 열등해 보이는데 왜 사라지지 않을까요? 현장의 이유는 합리적입니다.
- 앱 수의 문제: 대형 은행 인트라넷에는 SiteMinder가 보호하는 앱이 200~2000개 규모로 존재합니다. 상당수는 소스 코드 수정이 불가능한(벤더 폐업, 유지보수 계약 종료) 앱입니다.
- 헤더 결합도: 앱이 SM_USER 헤더에 직접 결합되어 있어, IdP만 바꾸는 것이 아니라 앱의 인증 연동부를 건드려야 합니다.
- 안정성 실적: 20년간 검증된 시스템을 "잘 돌아가는데 왜 바꾸냐"는 관성이 강합니다. 금융권은 특히 가용성 사고에 민감합니다.
- 규제와 감사: 인증 체계 변경은 보안성 심의, 감독 당국 보고 등 절차 비용이 큽니다.
- 조직 지식: 정책 수천 개의 의미를 아는 사람이 퇴직하면, 마이그레이션은커녕 현행 유지도 어려워집니다 — 역설적으로 이것이 전환을 서둘러야 할 이유이기도 합니다.
결국 대부분의 조직이 선택하는 길은 빅뱅 교체가 아니라 수년에 걸친 하이브리드 공존입니다. Keycloak 같은 모던 IdP를 옆에 세우고, SAML/OIDC 브리지와 프록시 패턴으로 앱을 한 묶음씩 옮기는 것입니다. 이 전략은 후속 글에서 상세히 다룹니다.
운영 관점 체크리스트 — SiteMinder 환경을 물려받았다면
마이그레이션 이전에, 지금 운영 중인 SiteMinder 환경에서 최소한 확인해야 할 것들입니다.
# Policy Server 상태 확인 (smpolicysrv 프로세스와 포트)
ps -ef | grep smpolicysrv
netstat -an | grep 44443
# Web Agent 로그에서 인증 실패 패턴 확인
tail -f /opt/ca/webagent/log/WebAgent.log | grep -i "denied\|reject"
# 정책 스토어 export (XPSExport — 인벤토리 작성의 출발점)
XPSExport policy-export.xml -xb -vT
# Agent 설정 덤프 (ACO 파라미터 확인)
# Admin UI 또는 XPSExplorer에서 AgentConfigObject 조회
- Agent Key 롤오버 주기가 설정대로 도는지, 롤오버 시 간헐 401이 발생하지 않는지 확인합니다.
- Agent Cache TTL이 과도하게 길어 정책 변경이 반영되지 않는 문제가 없는지 점검합니다.
- 인증서 만료(페더레이션 서명 인증서, Policy Server 간 통신)는 고전적인 장애 원인입니다.
- XPSExport 결과물은 마이그레이션 인벤토리의 1차 자료가 됩니다. realm/rule/policy/response 개수와 사용 중인 인증 스킴 분포를 먼저 뽑아 보십시오.
안티패턴 모음
현장에서 자주 보이는 SiteMinder 안티패턴입니다. 새 시스템 설계 시 반면교사로 삼을 만합니다.
- 만능 realm: 루트(/)에 하나의 realm을 걸고 모든 앱을 한 정책으로 보호 — 앱별 차등 보안이 불가능해지고 마이그레이션 단위 분리도 어려워집니다.
- response 남발: 앱마다 커스텀 헤더 response를 수십 개 만들어, 정책 스토어가 앱 설정 저장소처럼 변질된 경우. 헤더 인벤토리 없이는 어떤 앱이 어떤 헤더에 의존하는지 알 수 없게 됩니다.
- OnAuthAccept 룰에 비즈니스 로직: 인증 이벤트 룰로 사용자 속성을 조작하거나 외부 시스템을 호출하는 구성 — 장애 전파의 원인이 됩니다.
- Session Store 없는 강제 로그아웃 요구: stateless 쿠키 모델에서 "특정 사용자 즉시 차단"은 불가능한데, 이를 Agent 캐시 플러시로 흉내 내다 전체 성능 저하를 일으키는 사례가 있습니다.
- 문서화되지 않은 FCC 커스터마이징: login.fcc에 자바스크립트로 구현된 비밀번호 정책, 공지 팝업 등 — 마이그레이션 시 빠뜨리기 쉬운 숨은 요구사항입니다.
마치며
SiteMinder는 "중앙 정책 결정 + 엣지 집행 + 헤더 기반 신원 전달"이라는, 이후 모든 WebSSO와 심지어 모던 서비스 메시 인가 패턴에까지 이어지는 아키텍처 원형을 만들었습니다. 2026년의 시선으로 보면 비표준 쿠키, 헤더 신뢰 모델, 벤더 종속이라는 한계가 뚜렷하지만, 그 설계 의도를 이해하는 것은 레거시 폄하가 아니라 마이그레이션 성공의 전제 조건입니다.
다음 글에서는 이 글의 내용을 토대로 SiteMinder에서 Keycloak으로의 마이그레이션 전략 — 인벤토리, 객체 매핑, 공존 아키텍처, 점진적 비밀번호 캡처까지 — 을 실전 로드맵 수준으로 다룹니다.
참고 자료
- Broadcom SiteMinder Tech Docs
- Broadcom Symantec SiteMinder 제품 페이지
- SAML 2.0 Core 사양 (OASIS)
- OpenID Connect Core 1.0
- RFC 6749 — The OAuth 2.0 Authorization Framework
- RFC 9700 — Best Current Practice for OAuth 2.0 Security
- OAuth 2.1 draft (draft-ietf-oauth-v2-1)
- Keycloak 공식 문서
- Keycloak 릴리스 노트
- OWASP Authentication Cheat Sheet
- W3C WebAuthn Level 3