Happy 2020, team! Thanks much for the notes, Marco. I have had a chance to review the design notes and the insofar implementation and have a few proposals to discuss:
- "Chain Authentication" as the default authentication type Narrowing down the types to two only, where default Syncope authentication then becomes a standard module in the chain that is present an active by default. This allows Syncope authentication to be used in the chain along with others, (i.e. Use user+password with LDAP/DB, and if not found, fall back into Syncope). - Success criteria for the chain? Seems like the authn policy also needs to establish a success criteria for the chain of authN modules that execute. As in, "Should we consider it a successful authn event if all modules can validate the user? Or maybe only some of them?", etc. - Order-able authentication chain? My assumption is that authN modules registered in a chain are or should be orderable and sortable; for discussion's sake, let's say by a numeric value assigned to the module. Such that, when we go through the chain, sort it by an order, and then begin to execute each module to find the user. - Separation of MFA vs Primary AuthN modules I think MFA is most usually taken as 2FA. We'd have some number of modules that can support primary AuthN (first leg), and then we'd have a second set of MFA modules capable of responding to the second leg (and in theory more). So you login with X509 and then FIDO, or you login with Syncope and then OTP. If the chain is sortable/orderable, this would mean that the two sets (Primary AuthN & MFA AuthN modules) should be recognized differently by the chain, because you wouldn't want a scenario where you do FIDO first, and then LDAP. That seems odd. - Use JAAS for most authentication modules? It might be possible to take advantage of native JAAS functionality for a number of authN modules, such as LDAP, DB, Kerberos. I am not sure if we'd have to create new code for, say, LDAP authn where we could just take advantage of native JAAS? - WebAuthN should include U2F AFAIK, WebAuthN should auto-support U2F. I don't think we'd have a use case where someone would want to deploy Syncope with just U2F. Seems odd to me. - Policy assigned to realm? My understanding so far is that each realm is assigned an authentication policy, and the policy describes the "types of authentications that can be used in, say, a chain. I think this might require Realm selection first (i.e. in the UI) so we can look up the authentication policy, right? If so, the UI likely needs to be changed to implement some sort of flow where you ask for the Realm first, look up the policy and then decide the type of credentials that should be asked from the user. (userid+password, x509 cert, etc). In the case of MFA, we also need to figure out some sort of identifier (not always the username; there may not be a username) from the first leg that can be used to link the user to the MFA step. A typical example might be: - Pick Master realm - AuthN policy says to do LDAP and OTP - Show username+password for LDAP - On success, grab username (identifier) and locate device record for OTP - Registration flow for OTP if device not found based on the username (identifier) - Do OTP - Proceed. Am I on the right path? Any of this make sense? On a semi-related note, I have sort of had an internal/personal TODO item to add CAS SP support to Syncope (sort of like what exists for SAML2 SPs). I am not sure how popular or relevant this might be, and I was planning to do this just to learn Syncope+UI better. However, if this is something useful for Syncope, we could likely take that into consideration as well. Overall, the task here is a very large piece of work and so if agreed, the CAS piece can become a sub-task somewhere down the road. --Misagh ----- Original Message ----- > From: "Marco Di Sabatino Di Diodoro" <marco.disabat...@tirasa.net> > To: "dev" <dev@syncope.apache.org> > Sent: Tuesday, September 3, 2019 11:46:50 AM > Subject: Re: [SYNCOPE-163] PR #103 design notes > Il 03/09/19 09:34, Francesco Chicchiriccò ha scritto: >> On 03/09/19 09:05, Misagh Moayyed wrote: >>> Hi Marco, >>> >>> I have begun to learn and study SYNCOPE-163 for which there is this pending >>> PR >>> by you: >>> https://github.com/apache/syncope/pull/103 >>> >>> Would you mind putting together a few notes/paragraphs on the high level >>> design, >>> abstractions and intention of each component on the wiki? Or if there is one >>> already, could you point me to it please? Any sort of documentation that you >>> can spare on the design would be most welcome, as time allows. >> Hi Misagh, >> welcome to Apache Syncope. >> >> Marco, I created >> >> https://cwiki.apache.org/confluence/display/SYNCOPE/Authentication+features >> >> which should be the right place where to put your thoughts about the >> authentication features to implement in Syncope 3.0. > > Hi Misagh, > > For SYNCOPE-163 I will try to describe what I did. We are still in an > initial phase, so there may be some changes on how it was designed. > I will add a brief description in the PR. > > M > >> >> Thanks! >> Regards. >> > -- > Dott. Marco Di Sabatino Di Diodoro > Tel. +39 3939065570 > > Tirasa S.r.l. > Viale Vittoria Colonna, 97 - 65127 Pescara > Tel +39 0859116307 / FAX +39 0859111173 > http://www.tirasa.net > > Apache Syncope PMC Member > http://people.apache.org/~mdisabatino/
