diff --git a/docs/admin/planning/delegated-user-admin.md b/docs/admin/planning/delegated-user-admin.md index cf99095321f..9e14fe7b4c4 100644 --- a/docs/admin/planning/delegated-user-admin.md +++ b/docs/admin/planning/delegated-user-admin.md @@ -4,5 +4,17 @@ tags: - planning --- -This is a placeholder +Delegated user administration is normally implemented via a website +where a privileged user can search / add / edit / delete people in +their organization. You will not be surprised to hear that this is an +identity management use case that Janssen Auth Server does not provide +out of the box. +But if you wanted to build a web site that performed this function, +you could use the SCIM protocol to do so. In your application, you +could read the user claims to find out the organization, role, or +other information about the person managing data. Then your web application +could use this information to make filters when making +SCIM calls. Or another handy trick is to put the person's role information +in an OAuth access token (using the Update Token script), and then use the +SCIM interception script to add the respective filters. diff --git a/docs/admin/planning/machine-to-machine.md b/docs/admin/planning/machine-to-machine.md index cf99095321f..abb138e8fe5 100644 --- a/docs/admin/planning/machine-to-machine.md +++ b/docs/admin/planning/machine-to-machine.md @@ -4,5 +4,17 @@ tags: - planning --- -This is a placeholder +OAuth gives us a perfect infrastructure for one machine (i.e. software) to +authenticate itself while calling an API of another machine: +the [Client Credential Grant](https://www.rfc-editor.org/rfc/rfc6749#section-4.4). +The software receiving the token can validate the access token signature, or +if it's a reference token, can use [OAuth Introspection](https://datatracker.ietf.org/doc/html/rfc7662). +For extra security, the software in question can also use [mutual TLS](https://www.rfc-editor.org/rfc/rfc8705.html) to authenticate. + +The OAuth Authorization Server can also send extra security context, like scopes +(which typically communicate the extent of access), or other information about +the software vendor or characteristics. + +Of course this requires the devices in this machine-to-machine scenario to have +a tcp stack (some constrained IOT devices only have a UDP stack). diff --git a/docs/admin/planning/passwordless-auth.md b/docs/admin/planning/passwordless-auth.md index cf99095321f..f8973346d1d 100644 --- a/docs/admin/planning/passwordless-auth.md +++ b/docs/admin/planning/passwordless-auth.md @@ -4,5 +4,27 @@ tags: - planning --- -This is a placeholder +Auth Server is not proscriptive about how an organization authenticates a +person. If you want to avoid passwords, that's great. Everyone knows +passwords are terrible. +Modern authentication flows use a series of web pages to mitigate sufficient +risk, enabling them to issue an assertion about the subject's identity. In +order to perform authentication, identification is a given. This implies that +all authentication flows normally start with the subject asserting some kind of +identifier: username, email address, phone number, or any other identifier that +uniquely identifies a person. Auth Server is not opinionated about how you do +this. You could prompt the user to enter their identifier. Or for example, you +could ask the user to scan a QR code, and identify a phone identified with a +person. + +With identification done, Auth Server can present any number of additional +web pages to establish that identity. These pages can ask for any "factors". +For example, if you want to perform two factor authentication in one step, +you could use a FIDO 2 credential, which combines possession with either +knowledge or biometric. But in practice, you could ask for any one or more +combination of credentials--none of which must include password. + +Net-net, "passwordless" is really just marketing jargon. Normally it implies +some kind of risk assessment to optimize user experience. If you can imagine +any such authentication flow, you can implement it in Auth Server. diff --git a/docs/admin/planning/stepped-up-auth.md b/docs/admin/planning/stepped-up-auth.md index cf99095321f..c6b1e5a3ead 100644 --- a/docs/admin/planning/stepped-up-auth.md +++ b/docs/admin/planning/stepped-up-auth.md @@ -4,5 +4,32 @@ tags: - planning --- -This is a placeholder +The holy grail of security policies since the introduction of RSA OTP tokens, +stepped-up authentication is when the subject is presented with an additional +authentication requirement, usually in response to perceived risk. As Jans +How do you decide when to invoke stepped-up authentication? As Auth Server is not +a policy enforcement point, or a policy management system, these two aspects are +out of scope. But once you make a runtime decision that you need more evidence +of identity, the OpenID Connect [Authentication Request](https://openid.net/specs/openid-connect-core-1_0.html#AuthRequest) has a few features that can help you out. +The first is `prompt=login`. This is a hint from the Relying Party to the +OpenID Provider that re-authentication is needed. Not all OpenID Connect +providers support this feature (for example, Google does not). However +Auth Server does currently support this parameter, although there is a +[feature request](https://github.com/JanssenProject/jans/issues/3006) to make it +optional. + +The second is `acr_values`. In Auth Server, this provides a hint to the +Auth Server to invoke a specific Person Authentication interception script. +Typically, this would specify your workflow for additional authentication. +If you are using Agama, you can also provide a hint for which Agama flow to +invoke by adding __. + +Another more esoteric strategy is to use UMA claims gathering. In this flow, +the subject's browser is directed to the claims gathering endpoint (i.e. +front channel), at which point the claims gathering script could invoke an +OpenID authentication, using the `prompt` and `acr_values` parameters mentioned +above. + +If you want to see an example of how a client implements stepped-up +authentication, you should checkout this [mod_auth_openidc wiki page](https://github.com/zmartzone/mod_auth_openidc/wiki/Step-up-Authentication).