Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

clarified current server behaviour #213

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

clarified current server behaviour #213

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
52 changes: 33 additions & 19 deletions adr/ADR-26.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -27,31 +27,44 @@ TLS information such as fully signed client certificates if presented during the

The authorization request will be sent to `$SYS.REQ.USER.AUTH` on the default
`$G` account, or a named account in server configuration mode. In operator mode,
it will utilize the connected account. The request will be signed by the
server's nkey and can be encrypted if configured.

The response to the request will be a signed user JWT that must be signed by the
declared issuer in server configuration mode or an account signing key in
operator mode. If the request was encrypted, the response can also be encrypted
for the issuing server. The request will contain a public user nkey that will be
required to be the subject of the user JWT response. An authorization service
can request that the client be bound to a different account.
it will utilize the connected account. The request will be a signed
`AuthorizationRequest` JWT signed by the server's nkey and can be encrypted if
configured.
Comment on lines +30 to +32
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Attempted to simplify, hopefully I interpreted this correctly.

Suggested change
it will utilize the connected account. The request will be a signed
`AuthorizationRequest` JWT signed by the server's nkey and can be encrypted if
configured.
it will utilize the connected account. The `AuthorizationRequest`, representing a JWT,
will be signed by the server's configured public nkey and optionally encrypted by a
configured xkey.


The response to the request is a `AuthorizationResponse` JWT. If the callout is
set to encrypt, the response will be encrypted for the server's nkey. The
decoded JWT will be issued by auth account nkey as configured in the server. In
operator mode, it is possibly for the `AuthorizationResponse` to be issued by an
a signing key for the auth account.
Comment on lines +34 to +38
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Again, hopefully interpreting correctly...

Suggested change
The response to the request is a `AuthorizationResponse` JWT. If the callout is
set to encrypt, the response will be encrypted for the server's nkey. The
decoded JWT will be issued by auth account nkey as configured in the server. In
operator mode, it is possibly for the `AuthorizationResponse` to be issued by an
a signing key for the auth account.
The expected response to the request is an `AuthorizationResponse` JWT. If encryption
is configured, the response must be encrypted by the server's configured xkey. The
embedded JWT is expected to be issued by the nkey configured on the server.
In operator mode, an alternate issuer to the JWT within `AuthorizationResponse` can
be a signing key of the configured nkey.


The response JWT has its `aud` (audience) field set to the server ID that was
specified in the request, and includes two fields, an `error` field where the
auth callout can return an error. Or a `jwt` field. In configuration mode, the
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
auth callout can return an error. Or a `jwt` field. In configuration mode, the
auth callout can return an error or a `jwt` field. In configuration mode, the

user will be issued by the configured auth account key, and the placement for
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
user will be issued by the configured auth account key, and the placement for
user will be issued by the configured auth account key, and the placement of

the user can be an account such as `$G` or some other account name configured
for the callout service. In operator mode, the user will be placed on the
account specified by the user JWT, provided the callout is allowed to place into
such account. Normal user JWT practice is supported: JWT can be issued by the
target account or one of its signing keys.

### Details and Security

The main security concerns with the auth callout proposal are spoofing of the
request or response. To address these concerns, the requests sent from the
server will be signed by the server's nkey and can be encrypted. The requests
will also contain a public user nkey that must be the subject of the response.
The responses, which are user JWTs, will be signed by an account nkey and can be
encrypted.
server will be signed by the server's nkey and can be encrypted. The server will
generate a server keypair and an xkey keypair on startup, which will be used to
sign and optionally encrypt the authorization requests.

The requests will also contain a public user nkey that must be the subject of
the response. The responses, which are `AuthorizationResponse` JWTs will always
be signed by the callout account (or one of its signing keys in operator mode),
and can be encrypted.

The server will be configured with an authorization callout issuer, which is a
public account nkey, in server configuration mode. The response must be signed
by this issuer and the subject must be the public user nkey from the request. In
operator mode, the response must be signed by the account bound to the client.
The server will generate a server keypair and an xkey keypair on startup, which
will be used to sign and optionally encrypt the authorization requests.
operator mode, the response must be signed by the account bound to the client or
one of its signing keys.

When the server receives a client connection request, it will call out to the
authorization service with a signed request if needed. The request is signed by
Expand Down Expand Up @@ -173,9 +186,10 @@ handle all authorization requests and determine which account each user should
be assigned to. This is primarily applicable in server configuration mode, but
can also be used in operator mode. In operator mode, the account that enables
authorization callouts will specify which accounts a client can be assigned to.
The response user JWT must be signed by the private key of one of these other
accounts, so that the server can verify that the owner of the new bound account
authorized the switch.
It is possible to relax such requirement by specifying "*" which means any
account. The user JWT returned must be signed by the private key of one of these
other accounts (or a signing key in operator mode), so that the server can
verify that the owner of the new bound account authorized the switch.

### TLS

Expand Down