B2B-Proxy — LSO Authentication Flow

Introduction / Limitation

The login via lso.volkswagen.de is mentioned only for human users using a browser. Agents should use the API-Gateway B2BSYS, because the LSO-login contains many redirects, Style-Sheets and Java-Scripts elements, that are hard to follow for an agent but give a nice user experiance for humans working with a browser.

LSO-AUTH-FLOW

1. First Requests of an URL secured behind lso.volkswagen.de. (e.g.: https://lso.volkswagen.de/one-kbp/)
2. the WebSEAL (ISAM-9) has no auth-session for this request. The WebSEAL sends its own login.html back instead of the required page. (response code 200 HTTP_OK)
3. This injected login.html page contains a meta refresh header and an onload java script line that should force the browser to request the Lona-Login page. (e.g.: https://lso.volkswagen.de/lona/login.do?... )
4. LONA executes the complete authentication handshake (no authorization!). The user has to give his credentials (User/Password, User/RSA-Token or PKI-x509 certificate) and LONA validates it.
5. After successful validation LONA sends a redirect to the initially requested URL with some additional EAI response headers.
6. The WebSEAL reads and then strips these EAI headers out of response and adds its own set-cookie headers into the response to establish the auth-session.
7. The Browse now follows the redirect and senda request to the initally requested URL. But now the requests contains the WebSEAL auth-session cookies.
8. The WebSEAL checks now the auth-session. If the session is valid and not timed out the request could pass the WebSEAL. The WebSEAL adds some header fields containing the UserId and the Authlevel to the request.
9. Every authenticated request will be send via a "Virtual Host Junction" to the B2B-Apache
10. The B2B-Apache trusts the header fields added by the WebSEAL and
    • checks authorization requirements (e.g. has the user the required LDAP resource)
    • conditional redirects triggered by a (B2B-)special ldap attribute
    • add the JWT-Token into the request header
11. Finally the request will be forwarded by the B2B-Apache to the application specific backend.

LSO-AUTH-Timeouts

There are two different Auth-Timeouts checked by the WebSEAL (ISAM-9):

• Inactive-Timeout = 31 minutes — If no request was sent by the client for time lasting longer than this timeout, the Auth-Session becomes invalid. If the client sends a requests after this he has to walk through the complete Auth-Flow again. This Timeout was chosen a litte bit longer than the max allowed Java-Session-Timeout (30 Minutes). So a valid Application-Session shouldn't be interrupted by this Timeout.
• Global-Timeout = 10 hours — An Auth-Session should not infinitely survive, even if there are permanently incomming requests. After the Global-Timeout is reached any Auth-Session becomes invalid and may has to be reesthablished by walking through the Auth-Flow.

Increasing these timeouts needs be to be approved by the Volkswagen Security Governace (ISSO)!