Initial check for delegated admin, m2m, passwordless and stepped-up (#…

…3018)

Initial content

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.

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).

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. 

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).