Support Single Sign On

[goautodial]

Support Single Sign On

[demianb]

Can you tell us more your single sign-on requirements? Our team is currently swamped with dev work. However, if you'll be sponsoring the development of this feature, we can prioritize this.

Please email me at demian @ goautodial.com.

[blaggacao]

Related to #47

[blaggacao]

@demianb Are there any plans with respect ot this or to #47 ? Might we help to sponsor such development?

Please just shout out if you feel we should discuss those requirements.

[blaggacao]

Perfect @lina2358 will be contacting you in a few days with a more detailed write-up.

[blaggacao]

Some quick shared understanding in preparation of said that write-up: https://openid.net/connect/

Uncertified: https://github.com/jumbojett/OpenID-Connect-PHP
Certified: https://bitbucket.org/PEOFIAMP/phpoidc/src/default/ (looks rather unusable)

Standard Claims do not contain role information (in GOautodial called "User Groups"). Hence, an additional claim that is application-specific (Goautodial-specific) is needed to assert roles ("User Groups").

Such a collision resistant claim could be:

• claims.idp.goaudodial.com/user-group

see also: Collision Resistance as per draft-ietf-oauth-json-web-token-32

   Collision-Resistant Name
      A name in a namespace that enables names to be allocated in a
      manner such that they are highly unlikely to collide with other
      names.  Examples of collision-resistant namespaces include: Domain
      Names, Object Identifiers (OIDs) as defined in the ITU-T X.660 and
      X.670 Recommendation series, and Universally Unique IDentifiers
      (UUIDs) [RFC4122].  When using an administratively delegated
      namespace, the definer of a name needs to take reasonable
      precautions to ensure they are in control of the portion of the
      namespace they use to define the name.

So, an example response from the IdP to GOautodial could look like:

{
   "sub"                                   : "alice",
   "email"                                 : "[email protected]",
   "email_verified"                        : true,
   "name"                                  : "Alice Adams",
   "given_name"                            : "Alice",
   "family_name"                           : "Adams",
   "phone_number"                          : "[phone]",
   "profile"                               : "https://c2id.com/users/alice",
   "claims.idp.goaudodial.com/user-group" : "supervisor"
}

This either creates a new user or authorizes an existing user, identified by sub - the Subject - Identifier for the End-User at the Issuer. Surely, User Groups need update on every login on-the-fly based on our claims.idp.goaudodial.com/user-group.

Eventually we might need to define further additional Claims based on the user fields in (also to consider Advanced Settings):

[blaggacao]

As for #47 - we can postpone that since it's use case would be to define and synchronize roles (User Groups) with an LDAP backend.

EDIT: Actually an external LDAP group syncer (somethig like this) would do the trick.