Decompositioning, implement Fosite #62

aeneasr · 2016-03-22T15:15:35Z

This PR is a refactor and a partial re-code of Hydra. It will mark version 0.1-beta and will include

Tagline: "A micro-service OAuth2, OpenID Connect and policy decision point provider written in Go". Check also this milestone: https://github.com/ory-am/hydra/milestones/0.1-beta

aeneasr · 2016-03-22T15:15:45Z

@leetal keep an eye out for this one :)

leetal · 2016-03-22T15:20:28Z

@arekkas i sure will! :)
Den 22 mars 2016 16:15 skrev "Aeneas" notifications@github.com:

@leetal https://github.com/leetal keep an eye out for this one :)

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#62 (comment)

aeneasr · 2016-03-22T15:31:35Z

Repositories relevant for the refactor:

https://github.com/ory-am/hydra-signup-react (exemplary sign up app in react)
https://github.com/ory-am/hydra-singin-react (exemplary sign in & consent app in react)

aeneasr · 2016-03-23T12:41:10Z

The following chart is a very basic architecture overview.

CLI

The CLI hydra will replace the functionality that currently resides in hydra-host and talk through HTTP REST with hydra-host. The admin needs to log in using app credentials. If no app is registered in Hydra, a OTP (one time password) will be printed to stdout by hydra-host. The admin needs to use that OTP in order to create the first administrative client.

idp.hydra.abc.com

I decided to move the identity provider part away from Hydra's core. Instead, it will reside in a microservice. Anyone who wishes to use LDAP or an existing user database as an identity source can do that by implementing the required HTTP REST interfaces (not defined yet).

Identity provider(s) will be added using the CLI: hydra idp add http://...

connector.hydra.abc.com

The connector is responsible for delegating a user to Google, Microsoft and other third party authentication services and returning "user info" to hydra. Hydra will then use that user info to find a match at the identity provider and confirm that the user exists. The matching will be done internally in hydra (currently known as "oauth2 connection")

Connectors will be added using the CLI: hydra connector add http://....

Resource Provider Endpoint

The middleware and client library will be rewritten and offer two interface:

Check if a token is valid (checks token expiry, token revokation, scope)
Do what 1 does plus access control through policies

aeneasr · 2016-03-23T12:42:22Z

The reworkings of connectors and identity providers let us additionally paralelize lookups with high efficiency. Cash. :)

aeneasr · 2016-03-23T15:02:18Z

endpoint/oauth2.go

+
+}
+
+func (o *OAuth2Handler) TokenHandler(w http.ResponseWriter, r *http.Request, _ httprouter.Params) {


god, this looks so much cleaner already..

aeneasr · 2016-03-23T15:09:38Z

Separating idp.hyra.abc.com, singin.hydra.abc.com and connector.hydra.abc.com is maybe not a good idea. The question is, if idp.hydra.abc.com is even required and if singin and connector should be one. It might be good if hydra took over a lot of the complexity and on the same time, it complicates service flows.

aeneasr · 2016-03-23T15:13:18Z

Complicated: The login endpoint could redirect back to hydra which would redirect that request to Google, MS, and so on. The callback would be a hydra endpoint which would validate the authentication request through a "connection" database lookup and a quick check in at the idp and redirect to the consent endpoint which would issue the consent token.

aeneasr · 2016-03-23T15:14:57Z

Alternative: The login endpoint handles all the third party authentication on its own and is simply responsible for returning a consent token. This would require much more sophisticated login / consent endpoints

aeneasr · 2016-03-29T12:17:43Z

One question that has me spinning in circles is how to handle social / remote logins. There are two possibilities I see right now.

Terminology:

IdP(s): Identity Provider(s)
Remote / Social IdP: This could be Google, Microsoft, ...
Local IdP: In monolithic applications, there is always a "user database" where the username, email and password are stored and retrieved. A local IdP is a such a user database which is usually under full control of the hydra administrator and is run in the same network or domain.

The remote party is seen as a standalone IdP

The remote idps (e.g. google) are considered a local idp: When the users signs in using a social login, no lookup is made if that user exists at the local idp. This basically means that we can skip the sign up process.

Workflow (simplified)

User chooses to use google for authentication
User is redirected to https://hydra.com/oauth2/auth?idp=google&client_id=...
User is redirected to https://google.com/sign-in
After successful authorization at google, the user is redirected to e.g. https://hydra.com/idp/google/callback
Hydra authenticates the user / validates the request by e.g. decoding the id token or making some sort of request to google
Hydra asks for the users consent
Hydra issues an authorization code / access token

Pro:

Reduced complexity: No roundtrip or registration at the "local" identity provider required when using social logins
No need to introduce a functionality like "social connectors" because we can use social idps in the same fashion we use local idps.

Cons:

Not sure how this scenario would work out if local and social IdPs are used. Because local IdP would create a user account but social IdP would not.
Not sure how to fetch user data in an orderly fashion from social IdPs. We would need some sort of adapter, but user profile requirements vary a lot across projects.
Any user can simply "sign up/in" using a social IdP (if activated). There is no "control" possible. Not sure how banning accounts, invitation only sign up and similar things would work.
If the remote party discontinues services or bans the user account, the local user account will be lost as well.

The remote party acts as an intermediate connector

In contrary to above, the remote party is an identity provider as well, but hydra acts as a bridge between it and the local idp. Every user requires thus an account at the local idp and the remote idp in order to sign in.

Workflow (simplified)

User chooses to use google for authentication
User is redirected to https://hydra.com/oauth2/auth?connector=google&client_id=...
User is redirected to https://google.com/sign-in
After successful authorization at google, the user is redirected to e.g. https://hydra.com/connectors/google/callback
Hydra authenticates the user / validates the request by e.g. decoding the id token or making some sort of request to google
Hydra checks the connection database. It contains fields remote_id, local_id and connector. If the user id returned by the connector exists, hydra uses the local id for further lookup.
Hydra checks the local IdP(s) for the found local user id and may ask if that user can be authenticated (this could also be done through policies)
If all of the above was successful, hydra will ask for the user's consent
Hydra issues an authorization code / access token

Pro / Con: TBD

aeneasr · 2016-03-30T17:17:35Z

client/client.go

@@ -20,9 +20,11 @@ type Context struct {
 }

 type Client interface {
-	TokenFromRequest(r http.Request) string
-
 	ActionAllowed(token string, action *Action) (*Context, error)

 	Authorized(token string, scopes ...string) (*Context, error)


There will be no more middleware, just one client. This will clean up the code base a lot. This interface should basically be implemented by any client in any language. Maybe we can use something like Thrift to build a client library for various languages

aeneasr · 2016-03-30T17:42:14Z

Connection needs an endpoint which returns

{
   Authorization: 'bearer .....',
}

or some other value for non-OAuth2 requests. This allows for sign up trickery

aeneasr · 2016-04-13T14:17:12Z

Alternative: The login endpoint handles all the third party authentication on its own and is simply responsible for returning a consent token. This would require much more sophisticated login / consent endpoints

is actually the smarter choice, if the endpoint is returning a "connection token" including the remote_id

aeneasr · 2016-04-22T09:00:46Z

The consent token should be able to carry a remote subject and id

aeneasr · 2016-04-22T12:11:35Z

2FA

https://github.com/google/google-authenticator/wiki/Key-Uri-Format

https://tools.ietf.org/html/rfc6238

aeneasr · 2016-04-22T12:13:05Z

https://github.com/pquerna/otp

aeneasr · 2016-04-22T12:29:48Z

I have decided to switch from postgres to RethinkDB and use the changes() feature to minimize db queries and significantly increase performance.

aeneasr · 2016-05-01T14:22:55Z

http://openid.net/specs/openid-connect-core-1_0.html#ServerMTI

aeneasr · 2016-05-02T11:59:08Z

https://community.pingidentity.com/servlet/fileField?retURL=%2Fapex%2FPingIdentityArticle%3Fid%3DkA340000000Gs7WCAS&entityId=ka340000000GvdRAAS&field=Associated_File__Body__s

aeneasr · 2016-05-08T15:59:21Z

http://docs.hdyra.apiary.io/#

iOliverNguyen · 2016-05-11T01:53:58Z

Could you list all Hydra APIs (implemented or will be implemented when #62 is merged) in Apiary? This would help us decide whether Hydra is fitted to our system. Thank you a lot :)

aeneasr · 2016-05-11T05:53:30Z

Already on it :)

aeneasr · 2016-05-29T09:49:51Z

0.1-beta is ready. Please try things, and break them. :D

tacurran · 2020-07-15T11:51:06Z

@aeneasr good history and well written too

aeneasr added the feat New feature or request. label Mar 22, 2016

aeneasr self-assigned this Mar 22, 2016

aeneasr added this to the 0.1-beta milestone Mar 22, 2016

aeneasr mentioned this pull request Mar 22, 2016

Adding basic LDAP package #57

Closed

aeneasr reviewed Mar 23, 2016
View reviewed changes

aeneasr reviewed Mar 30, 2016
View reviewed changes

aeneasr mentioned this pull request Apr 1, 2016

Implement default identity provider using postgres #63

Closed

8 tasks

aeneasr mentioned this pull request Apr 27, 2016

Fail to execute "create a new client" in apiary docs #64

Closed

aeneasr added 2 commits May 14, 2016 22:16

restructure

7bd22eb

fosite preview

20426eb

Aeneas Rekkas (arekkas) added 4 commits May 26, 2016 12:38

rethink db jwk

a26d925

finished rethinkdb adapters

242f5d0

test pass

a352d05

goimports, docker travis

d3c44e6

aeneasr force-pushed the refactor branch from 15436d0 to d3c44e6 Compare May 26, 2016 22:43

Aeneas Rekkas (arekkas) and others added 20 commits May 27, 2016 11:19

unstaged

ad2a0cf

unstaged

e94a94c

unstaged

2153578

unstaged

1903ec5

unstaged

56ba5dc

unstaged

4c2b725

unstaged

27e3e3d

unstaged

5151c3e

rethinkdb finalization

a56923e

unstaged

54bbab6

unstaged

c9446b4

unstaged

c0bdfd3

unstaged

4620f55

unstaged

f005463

unstaged

d9d2c06

unstaged

0b0f6b4

unstaged

8cf073a

unstaged

f407005

unstaged

a3622bb

fix travis

11bfe74

aeneasr merged commit 00fd93c into master May 29, 2016

aeneasr deleted the refactor branch July 25, 2016 12:34

flotho mentioned this pull request Dec 29, 2016

[DOC]How to implement connector for LDAP with new identity workflow #339

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Decompositioning, implement Fosite #62

Decompositioning, implement Fosite #62

aeneasr commented Mar 22, 2016 •

edited

Loading

aeneasr commented Mar 22, 2016

leetal commented Mar 22, 2016

aeneasr commented Mar 22, 2016

aeneasr commented Mar 23, 2016

aeneasr commented Mar 23, 2016

aeneasr Mar 23, 2016

aeneasr commented Mar 23, 2016

aeneasr commented Mar 23, 2016

aeneasr commented Mar 23, 2016

aeneasr commented Mar 29, 2016

aeneasr Mar 30, 2016

aeneasr commented Mar 30, 2016

aeneasr commented Apr 13, 2016

aeneasr commented Apr 22, 2016

aeneasr commented Apr 22, 2016

aeneasr commented Apr 22, 2016

aeneasr commented Apr 22, 2016

aeneasr commented May 1, 2016

aeneasr commented May 2, 2016

aeneasr commented May 8, 2016

iOliverNguyen commented May 11, 2016 •

edited

Loading

aeneasr commented May 11, 2016

aeneasr commented May 29, 2016

tacurran commented Jul 15, 2020


		}

		func (o OAuth2Handler) TokenHandler(w http.ResponseWriter, r http.Request, _ httprouter.Params) {

Decompositioning, implement Fosite #62

Decompositioning, implement Fosite #62

Conversation

aeneasr commented Mar 22, 2016 • edited Loading

aeneasr commented Mar 22, 2016

leetal commented Mar 22, 2016

aeneasr commented Mar 22, 2016

aeneasr commented Mar 23, 2016

CLI

idp.hydra.abc.com

connector.hydra.abc.com

Resource Provider Endpoint

aeneasr commented Mar 23, 2016

aeneasr Mar 23, 2016

Choose a reason for hiding this comment

aeneasr commented Mar 23, 2016

aeneasr commented Mar 23, 2016

aeneasr commented Mar 23, 2016

aeneasr commented Mar 29, 2016

The remote party is seen as a standalone IdP

The remote party acts as an intermediate connector

aeneasr Mar 30, 2016

Choose a reason for hiding this comment

aeneasr commented Mar 30, 2016

aeneasr commented Apr 13, 2016

aeneasr commented Apr 22, 2016

aeneasr commented Apr 22, 2016

aeneasr commented Apr 22, 2016

aeneasr commented Apr 22, 2016

aeneasr commented May 1, 2016

aeneasr commented May 2, 2016

aeneasr commented May 8, 2016

iOliverNguyen commented May 11, 2016 • edited Loading

aeneasr commented May 11, 2016

aeneasr commented May 29, 2016

tacurran commented Jul 15, 2020

aeneasr commented Mar 22, 2016 •

edited

Loading

iOliverNguyen commented May 11, 2016 •

edited

Loading