Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

 

Federated Login

Short description

Federated login is used to provide user information

Input

User information (e.g. name, email, organization) typically via a SAML assertion

Output

Factor request

Advantages


Drawbacks/Risks

ActivitySubactivitySubsubactivity

Mapping

I (Identity/Identification)

F (Factor) → 1F if first factor, 2F if second factor

Mandatory/optional?

(typically)

Input

(typically)

Output

(typically)

(Security) risks if omitted

(general)

Dependencies

(could be quite specific)

Increases/Decreases LoA

(general)

FRq 1) 2FA token request

1.0) Should we have a first factor authentication subactivity here as a gatekeeper for "User provides user info"

FRq.UI 1.1) User provides user info

F_request

(e.g. 2F_request if second factor is requested)

mandatoryuser information (e.g. name, email, organization, e.g. via SAML assertion)token request
  • First check to be entitled to register 2FA token (e.g. federated login, email address is present which is associated with user/org. LDAP)
Eligibility either needs to be checked in 1.1 or 3.1N/AFReg 2) 2FA (pre-)registrationFReg.Sel 2.1) User selects factorN/A, see F_selectoptional

FReg.Authc 2.2) User performs authentication with that factor for binding and to prove possession/knowledge/...

N/A, see F_authenticate
optionalIdent 3) Identification
(eligibility check;identity vetting using ID doc or alternative identity assertion method;unsure match of the person and her digital identity)

Ident.Sched 3.0) Identification session arrangement and scheduling (!optional)

I_scheduleIdent.ElegC 3.1) Check eligiblity of user & possession of first factor

I_checkEligibility

1F_authenticate

optional if already performed in 1.1

Ident.UVet 3.3) Vet identity of user

Ident.UVet.CkClm 3.3.1) Compare claimed/transmitted/spoken information with user's identity proof (e.g. ID doc, activation code)I_vet_????mandatory

Ident.UVet.ULive 3.3.2) Perform Liveness Check

(e.g. ID doc photo vs. real life face/ selfie)

I_vet_livenessIdent.UVet.IDVal 3.3.3) Check user's identity proof with its original source for validityI_vet_originalSourceoptionalIdent.UVet.Rec 3.3.4) Record identity proof (par of ID doc, or just note success???)I_recordFBind 4) Token bindingFBind.Poss 4.1) User chooses own token or handover of token to user (possession)F_selectoptional when activity 2 took place

FBind.DigID 4.2) Bind factor to digital ID

F_bind

mandatory,

may already be performed in step 2

precondition: successful 3.2.1)

FBind.FPoss 4.3) Token-proof of-possession (e.g. test authentication)2F_authenticateoptionalFBind.FAct4.4) Factor activation & record

F_activate

F_record

mandatory

precondition: successful 3.2.1

FBind.FAck 4.5) Inform user about factor activationF_confirmActivation2FA token request2FA token (pre-)registrationIdentificationToken binding1.1) User provides user info2.1) User selects 2FA token2.2) User performs authentication with that token to prove possession3.1) Eligibility check of user3.2) Vet identity of user4.1) User chooses own token or handover of token to user4.2) Bind token to digital ID4.3) Token-proof-of-possession4.4) Token activation & record4.5)Inform user3.2.1) Compare claimed/transmitted/spoken information with user's identity proof3.2.2) Check user's identity proof with its original source for validity3.2.3) Record identity proofMethodLive video

(tick)

federated login

(tick)(error)

(error)

(checked in 1.1 via login)

...