feat: saml application configuration for login version (#9351)

# Which Problems Are Solved

OIDC applications can configure the used login version, which is
currently not possible for SAML applications.

# How the Problems Are Solved

Add the same functionality dependent on the feature-flag for SAML
applications.

# Additional Changes

None

# Additional Context

Closes #9267
Follow up issue for frontend changes #9354

---------

Co-authored-by: Livio Spring <livio.a@gmail.com>

docs/docs/guides/integrate/login-ui/oidc-standard.mdx

@@ -10,9 +10,9 @@ The following flow shows you the different components you need to enable OIDC fo
 ![OIDC Flow](/img/guides/login-ui/oidc-flow.png)
 
 1. Your application makes an authorization request to your login UI
-2. The login UI proxies the request to the ZITADEL API. In the request to the ZITADEL API, a header to identify your client is needed.
+2. The login UI proxies the request to the ZITADEL API.
 3. The ZITADEL API parses the request and does what it needs to interpret certain parameters (e.g., organization scope, etc.)
-4. Redirect to a predefined, relative URL of the login UI that includes the authrequest ID ("/login?authRequest=")
+4. Redirect to a predefined, relative URL of the login UI that includes the authrequest ID ("/login?authRequest="), configurable per application.
 5. Request to ZITADEL API to get all the information from the auth request. This is optional and only needed if you like to get all the parsed information from the authrequest-
 6. Authenticate the user in your login UI by creating and updating a session with all the checks you need.
 7. Finalize the auth request by sending the session to the request, you will get the callback URL in the response
@@ -37,10 +37,10 @@ https://login.example.com/oauth/v2/authorize?client_id=170086824411201793%40your
 The auth request includes all the relevant information for the OIDC standard and in this example we also have a login hint for the login name "minnie-mouse".
 
 You now have to proxy the auth request from your own UI to the authorize Endpoint of ZITADEL.
-Make sure to add the user id of your login UI service/machine user as a header to the request: ```x-zitadel-login-client: <userid>```
+For more information, see [OIDC Proxy](./typescript-repo#oidc-proxy) for the necessary headers.
 
 :::note
-The user id sent in the 'x-zitadel-login-client' has to match to the PAT you are sending in the request.
+The version and the optional custom URI for the available login UI is configurable under the application settings.
 :::
 
 Read more about the [Authorize Endpoint Documentation](/docs/apis/openidoauth/endpoints#authorization_endpoint)
@@ -97,7 +97,7 @@ The latest session token has to be sent to the following request:
 
 Read more about the [Finalize Auth Request Documentation](/docs/apis/resources/oidc_service_v2/oidc-service-create-callback)
 
-Make sure that the authorization header is from the same account that you originally sent in the client id header ```x-zitadel-login-client: <userid>``` on the authorize endpoint.
+Make sure that the authorization header is from an account which is permitted to finalize the Auth Request through the `IAM_LOGIN_CLIENT` role.
 ```bash
 curl --request POST \
   --url $ZITADEL_DOMAIN/v2/oidc/auth_requests/V2_224908753244265546 \

docs/docs/guides/integrate/login-ui/saml-standard.mdx

@@ -10,9 +10,9 @@ The following flow shows you the different components you need to enable SAML fo
 ![SAML Flow](/img/guides/login-ui/saml-flow.png)
 
 1. Your application makes an SAML request to your login UI
-2. The login UI proxies the request to the ZITADEL API. In the request to the ZITADEL API, a header to identify your client is needed.
+2. The login UI proxies the request to the ZITADEL API.
 3. The ZITADEL API parses the request and does what it needs to interpret certain parameters (e.g., binding, nameID policy, etc.)
-4. Redirect to a predefined, relative URL of the login UI that includes the samlrequest ID ("/login?authRequest=")
+4. Redirect to a predefined, relative URL of the login UI that includes the samlrequest ID ("/login?authRequest="), configurable per application.
 5. Request to ZITADEL API to get all the information from the SAML request. This is optional and only needed if you like to get all the parsed information from the samlrequest-
 6. Authenticate the user in your login UI by creating and updating a session with all the checks you need.
 7. Finalize the SAML request by sending the session to the request, you will get the URL to redirect to or the body in the response
@@ -37,10 +37,10 @@ https://login.example.com/saml/v2/SSO?SAMLRequest=nJLRa9swEMb%2FFXHvjmVTY0fUhqxh
 The SAML request includes all the relevant information for the SAML standard, which includes the RelayState, the used binding and other information.
 
 You now have to proxy the SAML request from your own UI to the SSO Endpoint of ZITADEL.
-Make sure to add the user id of your login UI service/machine user as a header to the request: ```x-zitadel-login-client: <userid>```
+For more information, see [OIDC Proxy](./typescript-repo#oidc-proxy) for the necessary headers.
 
 :::note
-The user id sent in the 'x-zitadel-login-client' has to match to the PAT you are sending in the request.
+The version and the optional custom URI for the available login UI is configurable under the application settings.
 :::
 
 Read more about the [SSO Endpoint Documentation](/docs/apis/saml/endpoints#sso_endpoint)
@@ -87,14 +87,14 @@ Read the following resources for more information about the different checks:
 
 ### Finalize SAML Request
 
-To finalize the SAML request and connect an existing user session with it you have to update the SAML request with the session token.
+To finalize the SAML request and connect an existing user session with it you have to update the SAML Request with the session token.
 On the create and update user session request you will always get a session token in the response.
 
 The latest session token has to be sent to the following request:
 
 Read more about the [Finalize SAML Request Documentation](/docs/apis/resources/saml_service_v2/saml-service-create-response)
 
-Make sure that the authorization header is from the same account that you originally sent in the client id header ```x-zitadel-login-client: <userid>``` on the SSO endpoint.
+Make sure that the authorization header is from an account which is permitted to finalize the SAML Request through the `IAM_LOGIN_CLIENT` role.
 ```bash
 curl --request POST \
   --url $ZITADEL_DOMAIN/v2/saml/saml_requests/V2_224908753244265546 \

docs/docs/guides/integrate/login-ui/typescript-repo.mdx

@@ -130,7 +130,6 @@ To register your login domain on your instance, [add](/docs/apis/resources/admin
 When setting up the new login app for OIDC, ensure it meets the following requirements:
 
 - The OIDC Proxy is deployed and running on HTTPS
-- The OIDC Proxy sets `x-zitadel-login-client` which is the user ID of the service account
 - The OIDC Proxy sets `x-zitadel-public-host` which is the host, your login is deployed to `ex. login.example.com`.
 - The OIDC Proxy sets `x-zitadel-instance-host` which is the host of your instance `ex. test-hdujwl.zitadel.cloud`.