App Suite Security

SAML

BSI IT-Grundschutz 2023 sections covered by this page
  • APP.3.1

The OX App Suite SAML 2.0 implementation supports a subset of the bindings and profiles defined in the specification http://saml.xml.org/saml-specificationsopen in new window:

  • Profiles
    • Web Browser SSO Profile
    • Single Logout Profile
  • Bindings
    • HTTP-Redirect
    • HTTP-POST

General Assumptions

For production usage, the OX App Suite SAML implementation must always be supplemented by an operator-specific part. This part is responsible for most of the security-related aspects, i.e.

  • Providing keys for signing SAML messages and validation of signatures of incoming messages
  • Providing keys to decrypt incoming messages
  • Validation of authentication responses and assertions and providing the according user information
  • Validation of incoming logout requests (IdP-initiated single logout)
  • Validation of incoming logout responses (SP-initiated single logout)

OX provides default tooling for all those cases to enable operators to behave as strict and standard-compliant as possible, but has no influence on actual implementations. For compatibility reasons, operators can even implement nonstandard-compliant behavior. Any provided digital certificates are not validated by the core implementation. It's in the operators' responsibility to provide only verified certificates and to validate certificates contained in incoming SAML messages.

3rd Party Dependencies

OX App Suite uses several 3rd party libraries for (un-)marshalling SAML messages, encryption/decryption, creation and validation of digital signatures etc. Those are namely:

  • Shibboleth Open SAML-Java: Comprehensive SAML tooling
  • Apache Santuario: Creation and validation of digital XML signatures, encryption and decryption of SAML objects
  • Bouncy Castle Crypto API: Comprehensive cryptography toolkit

Authentication Flow

If the operator-specific part provides a signing key, every <AuthnRequest> is digitally signed. For every generated <AuthnRequest> some state is maintained internally to relate incoming <Response> messages to their original requests. The state is mapped to a unique identifier (128bit Java UUID) and passed around via the RelayState parameter.

Incoming <Response> messages are only accepted if a valid RelayState parameter is part of the request and the message can therefore be related to a previously sent <AuthnRequest>. <Response> messages are only considered eligible if they arrive within 5 minutes after sending out the according <AuthnRequest>. The unique ID of every incoming <Response> message is remembered for 120 minutes to detect possible replay attacks within that time frame. The final validation of the <Response> message and the contained Assertion elements lies within the responsibility of the operator specific part as well as the determination of the final user entity.

After a <Response> message has been validated and an according user entity has been determined, the user-agent (i.e. a web browser) is redirected to another endpoint where the final OX App Suite login process is performed, and a new session is created. This endpoint recognizes the requesting user by a formerly generated token consisting of two 128bit Java UUIDs. The token is linked with some server-side state and considered valid for one minute. The resulting session is treated as any other OX App Suite session. All common measures like IP checks, cookie hashes, separation of session ID and cookies are applied on subsequent requests.