Smarter by Design.Simpler for Business
TR7Enterprise Application Delivery & Security Platform
What is SAML 2.0?
Short answer
SAML 2.0 (Security Assertion Markup Language) is the OASIS standard that carries the user's identity between the IdP (Identity Provider) and the application, that is, the SP (Service Provider), with signed XML messages, and it is the widespread basis of enterprise SSO (OASIS SAML 2.0). When the user comes to the application, the user is redirected to the IdP and enters the password there; the IdP sends the user back to the application with a signed response that states who the user is. In TR7, AGS is the SP in this flow: the SAML 2.0-type Authentication Provider redirects the user to the IdP Single Sign-on URL address, verifies the signature of the returned response with the IdP Signing Certificate and reads the user information from the assertion in the response. IdPs that support SAML 2.0, such as Microsoft Entra ID, ADFS, Keycloak and Okta, are used with this type.
Where It Is Used in TR7
| Where | Field / label | What for |
|---|---|---|
| AGS → Authentication → Authentication Providers | Provider Type = SAML 2.0 | SSO with an enterprise IdP |
| AGS → Authentication → Authentication Providers | IdP Single Sign-on URL, IdP Entity ID (issuer), IdP Signing Certificate, Import Metadata | The address, identity and signing certificate of the IdP |
| AGS → Authentication → Authentication Providers | SP Entity ID, Assertion Consumer Service URL (default value /ags-portal/saml/acs) | The TR7 information written in the application record in the IdP |
| AGS → Authentication → Authentication Providers | Require Signed Assertions (on by default), Require Signed Response (off by default), Clock Skew Tolerance (default value 5 minutes) | How the IdP response is verified |
| AGS → Authentication → Authentication Providers | NameID Format, Force Re-Authentication, Authentication Request Binding | The content and transmission method of the authentication request sent to the IdP |
| AGS-enabled vService → Flowchart | Authentication Provider step | Adding the SAML 2.0 provider to the access flow |
Common Misconceptions
- "In SAML, the password comes to TR7." The user enters the password on the IdP's page; TR7 only receives and verifies the IdP's signed response.
- "SAML and OpenID Connect are the same thing." Both provide SSO; SAML uses a signed XML assertion, while OpenID Connect uses a JSON-based, signed ID token (What is OpenID Connect (OIDC)?).
- "The IdP signing certificate is entered once and never changes again." When the IdP renews its certificate, the certificate on TR7 must also be updated; otherwise the signature of the responses cannot be verified and login fails. The new metadata can be retrieved again with Import Metadata.
- "The clock difference is unimportant." The validity time of assertions is checked; if the difference between TR7 and the IdP exceeds the Clock Skew Tolerance value, the response is rejected (What is NTP; why is time synchronization important in TR7?).
How it is done in the documentation
