SAML 2.0 Setup
Configure Single Sign-On using SAML 2.0 for identity providers that support the SAML protocol. This guide covers generic SAML setup applicable to any compliant IdP.
Prerequisites
- A SAML 2.0 compliant identity provider (Okta, Azure AD, OneLogin, PingFederate, etc.)
- Admin access to your identity provider to create and configure applications
- A SecureCodingHub Org Admin account
Service Provider Details
These values are needed when configuring SecureCodingHub in your identity provider:
| Setting | Value |
|---|---|
| SP Entity ID | https://api.securecodinghub.com |
| ACS URL (Assertion Consumer Service) | https://api.securecodinghub.com/api/sch/auth/sso/callback/saml |
| SP Metadata URL | https://api.securecodinghub.com/api/sch/auth/sso/metadata |
| Name ID Format | urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress |
| Binding | HTTP-POST |
Step 1 — Configure Your Identity Provider
Step 2 — Configure SAML in SecureCodingHub
Step 3 — Test
Attribute Mapping
SecureCodingHub reads the following attributes from the SAML assertion:
| SAML Attribute | SecureCodingHub Field | Required |
|---|---|---|
NameID (email format) | Yes | |
firstName / givenName | First Name | No |
lastName / surname | Last Name | No |
Reading a SAML response in the wild
When SAML fails, the fastest path to a diagnosis is to inspect the actual SAML response rather than the symptom in the browser. Install a SAML tracer browser extension, reproduce the failed login, and look at the POST that the IdP sends to the ACS URL. Three fields tell you almost everything. The Issuer element should match the entityID published in your IdP metadata. The Audience element nested inside Conditions should match the SP Entity ID configured in SecureCodingHub. The Subject NameID should be the user's email address in the format you specified.
Beyond these fields, check the InResponseTo identifier if your IdP supports it, confirm the response is signed (the ds:Signature element is present), and verify the NotBefore and NotOnOrAfter timestamps are consistent with the current clock. Significant clock skew between IdP and SP causes silent rejection of otherwise valid assertions. If the response looks well-formed but the assertion is still rejected, copy the base64-encoded SAMLResponse value from the tracer and decode it offline. Reading the raw XML against the SAML 2.0 specification is the most reliable way to find a missing attribute or a misconfigured statement.
When to ask the IdP team versus the SP team for help
Most SAML support tickets can be triaged in under a minute if you know which side of the federation the error lives on. As a rule of thumb, audience and issuer mismatches are SP-side problems: the SecureCodingHub configuration expects values that the IdP is not producing, or it was configured against a different SP entity ID than the one the IdP is signing for. These are resolved by adjusting the SecureCodingHub SSO settings or the SP Entity ID and ACS URL in the IdP application configuration. Reach out to the SecureCodingHub side first.
Claim and attribute mapping issues are usually IdP-side. If users land in SecureCodingHub with missing first names, wrong email addresses, or unexpected role assignments, the IdP is emitting attributes the SP cannot consume. The IdP admin needs to add or rename claims in the application configuration. Certificate and signature failures are split: if the IdP certificate expired or rotated, that is an IdP-side fix. If SecureCodingHub stopped trusting a previously valid signature, the metadata or certificate stored on the SP side has gone stale and needs to be refreshed. When in doubt, capture the SAML tracer output and share it with both teams; the response itself shows which side owns the next move. See the SSO overview for protocol selection guidance.
SAML 2.0: frequently asked
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.