Implementing a "psuedo" device code flow for SAML-based authentication with AnyConnect gateways

[Info Skymem]

Hi,
thank you for your information.

On our website you can find email addresses of companies and people.
https://www.skymem.info

In short, it’s like Google for emails.

Best regards,
Robert,
Skymem team

On Sun, Nov 13, 2022 at 11:50 PM Rahul Rameshbabu
<sergeantsagara at protonmail.com> wrote:
>
> Hi,
>
> One use case I keep running into is authenticating on a headless system
> (imagine getty tty session only) with the SAML auth flow for an
> AnyConnect gateway. I would like to be able to do so without needing to
> remote port forward over ssh for the socket openconnect opens during the
> external browser auth process.
>
> Below is a diagram illustrating my high level understanding of the
> external browser auth process.
>
>          ------------------------      ------------------------
>          | Openconnect queries  |      | external-browser     |
>          | Anyconnect gateway   | ---> | capability available | ----
>          | capabilities         |      | , use if flagged for |    |
>          ------------------------      ------------------------    |
>                                                                    |
>                                                                    |
>          ------------------------      -------------------------   |
>          | Receive base64 blob  |      | socket server on port |   |
>          | sent by HTTP GET     | <--- | 29786. Spawn browser. | <--
>     ---- | through the browser  |      | Begin auth flow.      |
>     |    | (JavaScript does not |      -------------------------
>     |    | initiate the request |
>     |    ------------------------
>     |
>     |    --------------------------
>     |    | Socket server responds |
>     |    | to browser with an     |
>     |    | HTTP 302 to a "pretty" |
>     ---> | static success page    |
>          | provided by the        |
>          | AnyConnect gateway     |
>          --------------------------
>
> ref: https://gitlab.com/openconnect/openconnect/-/blob/ae96f9c8bb72466872edb82d9ec73add8630148b/hpke.c#L56-64
>
>
> Taking advantage of the external browser authentication architecture, I
> would like to attempt doing something like the diagram below.
>
>
>          ------------------------      ------------------------
>          | Openconnect queries  |      | external-browser     |
>          | Anyconnect gateway   | ---> | capability available | ----
>          | capabilities         |      | , use if flagged for |    |
>          ------------------------      ------------------------    |
>                                                                    |
>  -------------------------------------------------------------------------
>  | Psuedo-device code flow                                         |     |
>  |                                                                 |     |
>  |       ------------------------      -------------------------   |     |
>  |       | Receive base64 blob  |      | Output link + QR code |   |     |
>  |       | sent by HTTP GET     | <--- | (opened/scanned by    | <--     |
>  |  ---- | through the browser  |      | authenticating device)|         |
>  |  |    | (JavaScript does not |      -------------------------         |
>  |  |    | initiate the request)|                                        |
>  |  |    ------------------------                                        |
>  |  |                                                                    |
>  |  |    --------------------------     ---------------------------      |
>  |  |    | HTTP GET request fails |     | User copies base64 blob |      |
>  |  |    | because there is no    |     | into input prompt.      |      |
>  |  ---> | server to handle the   | --> | Openconnect establishes |      |
>  |       | request. base64 blob   |     | the VPN connection.     |      |
>  |       | stuck in URL bar       |     ---------------------------      |
>  |       --------------------------                                      |
>  |                                                                       |
>  -------------------------------------------------------------------------
>
> An external device is typically needed in MFA setups anyways, so moving
> the authetication process to an external device altogether seemed
> logical in this situation. I wanted to get opinions before starting any
> implementation work on this.
>
> -- Rahul Rameshbabu
>
>
> _______________________________________________
> openconnect-devel mailing list
> openconnect-devel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/openconnect-devel