Documentation

Application logic of the service provider.

HTTP handling of the service provider.

Store Assertions to prevent replay attack. Time argument is end of life (IDs may be garbage collected after that time). Iff assertion has already been stored and is still alive, return False.

(Microsoft Active Directory likes IDs to be of the form idhex digits: ID . cs . ("id" <>) . filter (/= -) . cs . UUID.toText $ createUUID. Hopefully the more common form produced by this function is also ok.)

Generate an AuthnRequest value for the initiate-login response. The NameIdPolicy is NameIDFUnspecified.

We do not use XML encryption (which appears to have been dead for years). We do not sign AuthnRequest values. Both encryption and signatures are optional, and rarely found in the wild. Security: (1) the AuthnReq ID is stored, and Assertions need to refer to a valid one in order to get a positive AccessVerdict by judge. AuthnResponses answering requests not originating from us will be ignored. (2) the request Issuer is there to help the IdP construct an AuthnResponse that we will accept. If it is changed by an attacker (either in the browser or on the wire, which is weakly procted by TLS) and passed on to the legitimate IdP, there will either be no access-granting AuthnResponse, or it will contain the wrong audience and be rejected by us. (3) The nameID policy is expected to be configured on the IdP side to not support any set of name spaces that overlap (e.g. because user A has an email that is the account name of user B).

The clock drift between IdP and us that we allow for.

FUTUREWORK: make this configurable

First arg must be comfortably earlier than the latter: if tolerance is one minute, then ("4:32:14" earlier "4:31:15") == True.

If this returns False you should be *more* inclined to throw an error, so a good calling pattern is unless (a earlier b) throwSomething, which is very different from when (b earlier a) throwSomething.

Even though this makes little sense, the standard requires to distinguish between "less" and "less or equal". For all practical purposes, you may consider noLater == earlier.

getSsoURI for links that have one variable path segment.

FUTUREWORK: this is only sometimes what we need. it would be nice to have a type class with a method getSsoURI for arbitrary path arities.

This monad collects errors in a writer, so that the reasons for access denial are as helpful as possible. It is a little like an exception monad, except you can throw several exceptions without interrupting the flow, and will get a list of them at the end.

NOTE: -XGeneralizedNewtypeDeriving does not help with the boilerplate instances below, since this is a transformer stack and not a concrete Monad.

Note on security: we assume that the SP has only one audience, which is defined here. If you have different sub-services running on your SP, associate a dedicated IdP with each sub-service. (To be more specific, construct AuthnReqs to different IdPs for each sub-service.) Secure association with the service can then be guaranteed via the Issuer in the signed Assertion.

3/4.1.4.2

, [3/4.1.4.3]; specific to active-directory: https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-single-sign-on-protocol-reference

judge does not consider the following parts of the AuthnResponse. * subjectID * scdAddress ("If any bearer SubjectConfirmationData includes an Address attribute, the service provider MAY check the user agent's client address against it." [3/4.1.4.3]) * astSessionIndex * astSubjectLocality ("This element is entirely advisory, since both of these fields are quite easily “spoofed,” but may be useful information in some applications." [1/2.7.2.1])

judge does check the rspStatus field, even though that makes no sense: most IdPs encrypt the Assertions, but not the entire response, and we make taht an assumption when validating signatures. So the status info is not signed, and could easily be changed by an attacker attempting to authenticate.

If this fails, we could continue (deny), but we stop processing (giveup) to make DOS attacks harder.

Check that the response is intended for us (based on config's finalize-login uri stored in JudgeCtx).

Check all SubjectConfirmations and Subjects in all Assertion. Deny if not at least one confirmation has method "bearer".

Locally check one SubjectConfirmation and deny if there is a problem. If this is a confirmation of method "bearer", return HasBearerConfirmation.