What does "federated SAML" actually mean?

Federated SAML refers to the trust relationship established between an identity provider (IdP) and a service provider (SP) so a user can authenticate once at the IdP and have that assertion accepted by the SP. The federation is the signed XML contract: each side trusts the other's metadata and signing certificate. SecureCodingHub becomes part of your federation once you upload the IdP metadata and the IdP knows the SP entity ID.

How do I rotate a SAML certificate without breaking logins?

A SAML certificate rotation is best executed with a brief overlap window. If your IdP supports publishing multiple signing certificates in metadata, add the new certificate before retiring the old one, and have SecureCodingHub re-fetch the IdP metadata so both certificates are trusted during the cutover. After the IdP starts signing with the new key, monitor logins for a day, then remove the old certificate from the metadata. The most common production outage is rotating without overlap, on a Friday.

SAML vs OAuth vs OpenID Connect — which one do I pick?

When teams compare SAML vs OAuth vs OpenID Connect, the practical answer is to follow operational fit. SAML 2.0 is the mature, XML-based federation standard, dominant in enterprise IdPs like ADFS and PingFederate. OAuth 2.0 alone is an authorization framework, not authentication. OpenID Connect layers identity on top of OAuth 2.0 and is the modern default for Azure AD and Okta. Either SAML or OIDC will give you equivalent SSO security with SecureCodingHub.

How do I decode a SAML response to troubleshoot a failure?

To decode a SAML response, capture the base64-encoded SAMLResponse parameter that the IdP posts to the ACS URL — a SAML tracer browser extension is the easiest way to grab it. Base64-decode the value to raw XML and inspect the Issuer, Audience, NameID, and timestamps. Most failures resolve once you compare those four fields against the values configured in the SecureCodingHub SSO settings and your IdP's application configuration.

SAML 2.0 설정

SAML 프로토콜을 지원하는 신원 공급자에 SAML 2.0을 사용하여 통합 로그인을 구성합니다. 이 가이드는 호환되는 모든 IdP에 적용 가능한 일반 SAML 설정을 다룹니다.

사전 요구 사항

SAML 2.0 호환 신원 공급자(Okta, Azure AD, OneLogin, PingFederate 등)
애플리케이션을 생성하고 구성하기 위해 신원 공급자에 대한 관리자 액세스
SecureCodingHub 조직 관리자 계정

서비스 공급자 세부 정보

신원 공급자에서 SecureCodingHub를 구성할 때 다음 값이 필요합니다:

설정	값
SP Entity ID	`https://api.limeplate.com`
ACS URL (Assertion Consumer Service)	`https://api.limeplate.com/api/sch/auth/sso/callback/saml`
SP 메타데이터 URL	`https://api.limeplate.com/api/sch/auth/sso/metadata`
Name ID 형식	`urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress`
Binding	`HTTP-POST`

1단계 — 신원 공급자 구성

새 SAML 애플리케이션 생성

신원 공급자의 관리자 콘솔에서 SecureCodingHub용 새 SAML 2.0 애플리케이션을 생성합니다.

ACS URL 및 Entity ID 설정

위의 서비스 공급자 세부 정보 테이블에서 ACS URL과 SP Entity ID를 IdP의 애플리케이션 구성에 복사합니다.

속성 매핑 구성

필수 email 속성을 NameID로 매핑합니다. 자동 프로필 채우기를 위해 선택적으로 firstName 및 lastName 속성을 매핑합니다.

IdP 메타데이터 URL 다운로드 또는 복사

다음 단계에서 SecureCodingHub를 구성할 때 IdP의 메타데이터 URL(또는 서명 인증서)이 필요합니다.

2단계 — SecureCodingHub에서 SAML 구성

SSO 설정 열기

조직 관리자로 로그인하고 사이드바에서 SSO 설정로 이동합니다.

SAML 프로토콜 선택

드롭다운에서 SSO 프로토콜로 SAML을 선택합니다.

IdP 메타데이터 URL 입력

신원 공급자의 메타데이터 URL을 붙여넣습니다. 이를 통해 SecureCodingHub가 엔드포인트와 인증서를 자동으로 발견할 수 있습니다.

서명 인증서 추가 (선택 사항)

IdP가 메타데이터 URL을 노출하지 않는 경우, IdP 서명 인증서를 직접 붙여넣습니다.

SSO 활성화 및 저장

SSO를 켜고 저장을 클릭하여 조직에 대한 SAML 인증을 활성화합니다.

app.securecodinghub.com/organization/sso

프로토콜

OIDC

OpenID Connect — 권장

SAML

SAML 2.0 페더레이션

SP entity ID — 이것을 IdP에 붙여넣기

https://api.limeplate.com/api/sch/auth/sso/saml/{orgId}

IdP 메타데이터 URL

https://idp.example.com/app/saml2/sso/metadata

X.509 서명 인증서

-----BEGIN CERTIFICATE----- MIICmzCCAYMCBgF8... ... -----END CERTIFICATE-----

SSO 활성화됨

3단계 — 테스트

익명 창 열기

관리자 계정과의 세션 충돌을 피하기 위해 비공개/익명 브라우저 창을 사용합니다.

SSO 로그인 페이지로 이동

app.securecodinghub.com으로 이동하여 SSO로 로그인을 클릭합니다.

기업 이메일 입력

시스템은 조직의 SSO 구성을 감지하고 IdP로 리다이렉트합니다.

IdP에서 인증

신원 공급자에서 로그인 흐름을 완료합니다. SecureCodingHub로 다시 리다이렉트되어 자동으로 로그인되어야 합니다.

속성 매핑

SecureCodingHub는 SAML 어설션에서 다음 속성을 읽습니다:

SAML 속성	SecureCodingHub 필드	필수
`NameID` (이메일 형식)	이메일	예
`givenName` (`…/claims/givenname`)	이름 (첫 부분 — 성과 연결되어 단일 표시 이름이 됨)	아니오
`surname` (`…/claims/surname`)	이름 (두 번째 부분 — 프로비저닝 시 givenName과 결합됨)	아니오

인증서 만료: SAML 인증서는 만료됩니다. 로그인 중단을 피하기 위해 만료 전에 인증서를 회전하도록 캘린더 알림을 설정하세요.

실제 SAML 응답 읽기

SAML이 실패할 때 진단까지 가장 빠른 경로는 브라우저의 증상이 아니라 실제 SAML 응답을 검사하는 것입니다. SAML tracer 브라우저 확장을 설치하고, 실패한 로그인을 재현하고, IdP가 ACS URL로 보내는 POST를 봅니다. 세 가지 필드가 거의 모든 것을 알려줍니다. Issuer 요소는 IdP 메타데이터에 게시된 entityID와 일치해야 합니다. Conditions 내부에 중첩된 Audience 요소는 SecureCodingHub에 구성된 SP Entity ID와 일치해야 합니다. Subject NameID는 지정한 형식의 사용자 이메일 주소여야 합니다.

이러한 필드 외에도, IdP가 지원하는 경우 InResponseTo 식별자를 확인하고, 응답이 서명되었는지 확인하고(ds:Signature 요소가 있음), NotBefore 및 NotOnOrAfter 타임스탬프가 현재 시계와 일치하는지 확인하세요. IdP와 SP 간의 상당한 시계 편차는 그렇지 않으면 유효한 어설션의 조용한 거부를 유발합니다. 응답이 잘 형성되어 보이지만 어설션이 여전히 거부되는 경우, 트레이서에서 base64로 인코딩된 SAMLResponse 값을 복사하여 오프라인으로 디코딩하세요. SAML 2.0 사양에 대해 원시 XML을 읽는 것이 누락된 속성 또는 잘못 구성된 명령문을 찾는 가장 신뢰할 수 있는 방법입니다.

IdP 팀과 SP 팀 중 누구에게 도움을 요청할지

대부분의 SAML 지원 티켓은 오류가 페더레이션의 어느 측에 있는지 알면 1분 미만으로 분류할 수 있습니다. 경험 법칙으로, audience 및 issuer 불일치는 SP 측 문제입니다: SecureCodingHub 구성이 IdP가 생성하지 않는 값을 예상하거나, IdP가 서명하는 것과 다른 SP entity ID에 대해 구성되었습니다. 이는 SecureCodingHub SSO 설정 또는 IdP 애플리케이션 구성의 SP Entity ID 및 ACS URL을 조정하여 해결됩니다. 먼저 SecureCodingHub 측에 문의하세요.

클레임 및 속성 매핑 문제는 일반적으로 IdP 측입니다. 사용자가 누락된 이름, 잘못된 이메일 주소 또는 예상치 못한 역할 할당으로 SecureCodingHub에 도착하는 경우, IdP는 SP가 소비할 수 없는 속성을 방출하고 있습니다. IdP 관리자는 애플리케이션 구성에서 클레임을 추가하거나 이름을 변경해야 합니다. 인증서 및 서명 실패는 나뉘어 있습니다: IdP 인증서가 만료되거나 회전된 경우, 이는 IdP 측 수정입니다. SecureCodingHub가 이전에 유효했던 서명을 신뢰하지 않는 경우, SP 측에 저장된 메타데이터 또는 인증서가 오래되어 새로 고쳐야 합니다. 의심스러울 때는 SAML 트레이서 출력을 캡처하고 양쪽 팀과 공유하세요. 응답 자체가 다음 움직임을 소유하는 측을 보여줍니다. 프로토콜 선택 안내는 SSO 개요를 참조하세요.

SAML 2.0: 자주 묻는 질문

"페더레이션 SAML"은 실제로 무엇을 의미합니까?

페더레이션 SAML은 사용자가 IdP에서 한 번 인증하고 그 어설션이 SP에 의해 수락될 수 있도록 신원 공급자(IdP)와 서비스 공급자(SP) 간에 설정된 신뢰 관계를 나타냅니다. 페더레이션은 서명된 XML 계약입니다: 각 측은 상대측의 메타데이터와 서명 인증서를 신뢰합니다. IdP 메타데이터를 업로드하고 IdP가 SP entity ID를 알면 SecureCodingHub가 페더레이션의 일부가 됩니다.

로그인을 중단하지 않고 SAML 인증서를 어떻게 회전합니까?

SAML 인증서 회전은 짧은 겹치는 윈도우로 가장 잘 실행됩니다. IdP가 메타데이터에 여러 서명 인증서를 게시하는 것을 지원하는 경우, 기존 인증서를 폐기하기 전에 새 인증서를 추가하고 SecureCodingHub가 IdP 메타데이터를 다시 가져오도록 하여 컷오버 동안 두 인증서가 모두 신뢰됩니다. IdP가 새 키로 서명을 시작한 후, 하루 동안 로그인을 모니터링한 다음 메타데이터에서 이전 인증서를 제거하세요. 가장 흔한 운영 중단은 금요일에 겹침 없이 회전하는 것입니다.

SAML 대 OAuth 대 OpenID Connect — 어떤 것을 선택해야 합니까?

팀이 SAML 대 OAuth 대 OpenID Connect를 비교할 때, 실용적인 답은 운영 적합성을 따르는 것입니다. SAML 2.0은 성숙한 XML 기반 페더레이션 표준이며 ADFS 및 PingFederate와 같은 엔터프라이즈 IdP에서 우세합니다. OAuth 2.0 자체는 인가 프레임워크이지 인증이 아닙니다. OpenID Connect는 OAuth 2.0 위에 신원을 계층화하며 Azure AD와 Okta의 최신 기본값입니다. SAML 또는 OIDC 중 하나가 SecureCodingHub와 동등한 SSO 보안을 제공합니다.

실패를 해결하기 위해 SAML 응답을 어떻게 디코딩합니까?

SAML 응답을 디코딩하려면 IdP가 ACS URL에 게시하는 base64로 인코딩된 SAMLResponse 매개변수를 캡처하세요 — SAML tracer 브라우저 확장이 이를 잡는 가장 쉬운 방법입니다. 값을 base64로 디코딩하여 원시 XML로 만들고 Issuer, Audience, NameID 및 타임스탬프를 검사합니다. 대부분의 실패는 SecureCodingHub SSO 설정 및 IdP의 애플리케이션 구성에 구성된 값과 이 네 가지 필드를 비교하면 해결됩니다.