From 4cb105178b8c706efbcd30152b2e421a815a15d0 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?J=C3=B6rn=20Friedrich=20Dreyer?= Date: Wed, 6 May 2020 15:47:19 +0200 Subject: [PATCH] update login flow MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: Jörn Friedrich Dreyer --- docs/login-flow.md | 80 +++++++++++++++++++--------------------------- 1 file changed, 33 insertions(+), 47 deletions(-) diff --git a/docs/login-flow.md b/docs/login-flow.md index 2175206f0a..ab450d9015 100644 --- a/docs/login-flow.md +++ b/docs/login-flow.md @@ -10,7 +10,7 @@ geekdocFilePath: login-flow.md ## Login Flow -The following sequence diagram describes the [openid connect auth flow](https://openid.net/specs/openid-connect-core-1_0.html#CodeFlowAuth): +The following sequence diagram describes the [openid connect auth code flow](https://openid.net/specs/openid-connect-core-1_0.html#CodeFlowAuth). The eight numbered steps and notes correspond to the [openid connect auth code flow steps](https://openid.net/specs/openid-connect-core-1_0.html#CodeFlowSteps). Example requests are based on the spec as well.: {{< mermaid class="text-center">}} sequenceDiagram @@ -21,8 +21,7 @@ sequenceDiagram participant user as User participant client as Client participant proxy as ocis-proxy - participant idp as external IdP - participant konnectd as ocis-konnectd IdP + participant idp as IdP participant glauth as ocis-glauth participant graph as ocis-graph participant accounts as ocis-accounts @@ -31,26 +30,33 @@ sequenceDiagram user->>+client: What is the content of my home? client->>+proxy: PROPFIND
no (or expired) auth - alt proxy can decide which idp to use - Note over client, idp: We may not be able to differentiate guests from users - proxy-->>client: 302 Found - Note over client, idp: HTTP/1.1 302 Found
Location: https://server.example.com/authorize?
response_type=code&
scope=openid%20profile%20email
&client_id=s6BhdRkqt3
&state=af0ifjsldkj
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb - else client needs to discover the idp - proxy-->>-client: 401 Unauthorized - Note over client, idp: Follow OpenID Connect Discovery protocol - Note over client, idp: Clients might fall back to the ocis server if the discovery failed.
We can provide a webfinger endpoint there to let guests use an idp
that is backed bythe accounts service. - Note over client, idp: For now, always use ocis well known endpoint to discover idp?
We can check the email in the accounts service. - end + Note over client,proxy: ocis needs to know the IdP that is
used to authenticate users. The
proxy will redirect unauthenticated
requests to that IdP. + proxy-->>-client: 302 Found + Note over client, idp: HTTP/1.1 302 Found
Location: https://server.example.com/authorize?
response_type=code&
scope=openid%20profile%20email
&client_id=s6BhdRkqt3
&state=af0ifjsldkj
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb + + Note over client, idp: We should follow the OpenID Connect Discovery protocol + Note over client, idp: Clients might fall back to the ocis server if the discovery failed.
We can provide a webfinger endpoint there to let guests use an idp
that is backed by the accounts service. + Note over client, idp: For now, clients can only handle one IdP, which is configured in ocis. client-->>client: 1. Client prepares an Authentication Request
containing the desired request parameters. - alt all users authenticated by an external idp - client->>+idp: 2. Client sends the request to the Authorization Server. - Note over client, idp: GET /authorize?
response_type=code
&scope=openid%20profile%20email
&client_id=s6BhdRkqt3
&state=af0ifjsldkj
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb HTTP/1.1
Host: server.example.com - Note over user, idp: 3. Authorization Server Authenticates the End-User. + client->>+idp: 2. Client sends the request to the Authorization Server. + Note over client, idp: GET /authorize?
response_type=code
&scope=openid%20profile%20email
&client_id=s6BhdRkqt3
&state=af0ifjsldkj
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb HTTP/1.1
Host: server.example.com + Note over user, idp: 3. Authorization Server Authenticates the End-User. + Note over idp,ldap: Either an IdP already exists or a new one is introduced. Since we are not yet using oidc discovery we can only use one IdP. + alt all users managed by konnectd/ocis + idp->>+glauth: LDAP query/bind + glauth->>+graph: GET user with Basic Auth
GraphAPI + graph->>+accounts: internal GRPC + accounts-->>-graph: response + graph-->>-glauth: OData response + glauth-->>-idp: LDAP result + Note over accounts,ldap: In case internal users are managed
in an external ldap they have to be
synced to the accounts service to
show up as recipients during sharing. + else all users authenticated by an external idp idp->>+ldap: LDAP query/bind ldap-->>-idp: LDAP result alt guest accounts managed in ocis / lookup using glauth proxy: + Note over idp,glauth: Idp is configured to use glauth as a
second ldap server. idp->>+glauth: LDAP query/bind glauth->>+graph: GET user with Basic Auth
GraphAPI graph->>+accounts: internal GRPC @@ -58,38 +64,18 @@ sequenceDiagram graph-->>-glauth: OData response glauth-->>-idp: LDAP result else guest account provisioned by other means - Note over idp, ldap: In case guest accounts are stored in an existing ldap they need to be synced to the accounts service to show up as recipients during sharing. + Note over accounts, ldap: In case guest accounts are managed
in an existing ldap they need to be
synced to the accounts service to
be able to login and show up as
recipients during sharing. end - - Note over user, idp: 4. Authorization Server obtains End-User Consent/Authorization. - idp-->>-client: 5. Authorization Server sends the End-User back
to the Client with an Authorization Code. - Note over client, idp: HTTP/1.1 302 Found
Location: https://client.example.org/cb?
code=SplxlOBeZQQYbYS6WxSbIA&state=af0ifjsldkj - - client->>+idp: 6. Client requests a response using the
Authorization Code at the Token Endpoint. - Note over client, idp: POST /token HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb - idp-->>-client: 7. Client receives a response that contains an
ID Token and Access Token in the response body. - Note over client, idp: HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache
{
"access_token": "SlAV32hkKG",
"token_type": "Bearer",
"refresh_token": "8xLOxBtZp8",
"expires_in": 3600,
"id_token": "a ... b.c ... d.e ... f" // must be a JWT
} - else all users managed by konnectd/ocis - client->>+konnectd: 2. Client sends the request to the Authorization Server. - Note over client, konnectd: GET /authorize?
response_type=code
&scope=openid%20profile%20email
&client_id=s6BhdRkqt3
&state=af0ifjsldkj
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb HTTP/1.1
Host: server.example.com - Note over user, konnectd: 3. Authorization Server Authenticates the End-User. - konnectd->>+glauth: LDAP query/bind - glauth->>+graph: GET user with Basic Auth
GraphAPI - graph->>+accounts: internal GRPC - accounts-->>-graph: response - graph-->>-glauth: OData response - glauth-->>-konnectd: LDAP result - Note over konnectd,ldap: In case the internal users come from an external ldap they have to be synced to the accounts service to show up as recipients during sharing. - - Note over user, konnectd: 4. Authorization Server obtains End-User Consent/Authorization. - konnectd-->>-client: 5. Authorization Server sends the End-User back
to the Client with an Authorization Code. - Note over client, konnectd: HTTP/1.1 302 Found
Location: https://client.example.org/cb?
code=SplxlOBeZQQYbYS6WxSbIA&state=af0ifjsldkj - - client->>+konnectd: 6. Client requests a response using the
Authorization Code at the Token Endpoint. - Note over client, konnectd: POST /token HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb - konnectd-->>-client: 7. Client receives a response that contains an
ID Token and Access Token in the response body. - Note over client, konnectd: HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache
{
"access_token": "SlAV32hkKG",
"token_type": "Bearer",
"refresh_token": "8xLOxBtZp8",
"expires_in": 3600,
"id_token": "a ... b.c ... d.e ... f" // must be a JWT
} end + Note over user, idp: 4. Authorization Server obtains End-User Consent/Authorization. + idp-->>-client: 5. Authorization Server sends the End-User back
to the Client with an Authorization Code. + Note over client, idp: HTTP/1.1 302 Found
Location: https://client.example.org/cb?
code=SplxlOBeZQQYbYS6WxSbIA&state=af0ifjsldkj + + client->>+idp: 6. Client requests a response using the
Authorization Code at the Token Endpoint. + Note over client, idp: POST /token HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb + idp-->>-client: 7. Client receives a response that contains an
ID Token and Access Token in the response body. + Note over client, idp: HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache
{
"access_token": "SlAV32hkKG",
"token_type": "Bearer",
"refresh_token": "8xLOxBtZp8",
"expires_in": 3600,
"id_token": "a ... b.c ... d.e ... f" // must be a JWT
} + client-->>client: 8. Client validates the ID token and
retrieves the End-User's Subject Identifier.