|
+4.11.2 Front-Channel Presentation |
4.11.2 Front-Channel PresentationIn the front-channel presentation model shown in Fig. 12, the IdP creates an assertion and sends it to the RP by means of a third party, such as the subscriber’s user agent. In the implicit flow and some forms of the hybrid flow of [OIDC], the assertion (i.e., the ID Token) is presented in the front channel. In the SAML Web SSO profile defined in [SAML-WebSSO], the SAML assertion is presented in the front channel. Fig. 12. Front-channel presentation
Front-channel presentation methods expose the assertion to parties other than the IdP and RP, which increases the risk of leaking the personal information included in the assertion. Additionally, there is an increased attack surface for the assertion to be captured and replayed by an attacker. As a consequence, front-channel presentation is not recommended when other mechanisms are available. The RP SHALL use the assertion identifier to ensure that a given assertion is presented at most once during the assertion’s validity time window. The RP SHALL protect itself against the injection of manufactured or captured assertions by using XSS and CSRF protection, rejecting assertions outside of the correct stage of a federation transaction, or other accepted techniques discussed in Sec. 3.11.1. Conveyance of the assertion from the IdP to the subscriber and from the subscriber to the RP SHALL be made over an authenticated protected channel. With general-purpose IdPs, it is common for front-channel communications to be accomplished using HTTP redirects, where the contents of the assertion are made available as part of an HTTP request URL. Due to the nature of the HTTP ecosystem, these request URLs are sometimes available in unexpected places, such as access logs, web proxies, and browser histories. These artifacts tend to live on long past the federation transaction and are available in other contexts, which increases the attack surface for reading the assertion. As a consequence, an IdP that uses HTTP redirects for the front-channel presentation of assertions SHALL encrypt all personal information in the assertion, as discussed in Sec. 3.13.3. Other front-channel presentation mechanisms that do not share these characteristics (e.g., HTTP form-post binding, application-specific URLs) SHOULD encrypt all personal information in the assertion. 1. Přehled
1.1 Odkazy1.2 Identifikované požadavky1.3 Související regulace2. Identifikované požadavky
3. Související regulace
|
