Example Identity Provider in GO

1,075 views
Skip to first unread message

Jan Olszak

unread,
Jun 4, 2016, 2:21:39 PM6/4/16
to ory-hydra
Hi,

I wrote a small example IdP for Hydra. It doesn't do much, but I believe it fully integrates with Hydra.


Comments and suggestions are welcomed.


Aeneas Rekkas

unread,
Jun 4, 2016, 3:27:48 PM6/4/16
to ory-...@googlegroups.com

Hi Jan,

very nice! I will take a look tomorrow / on monday. Stay tuned :)

--
You received this message because you are subscribed to the Google Groups "ory-hydra" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ory-hydra+...@googlegroups.com.
To post to this group, send email to ory-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ory-hydra/5ed8f7f0-992a-4842-975a-1b5e7904b39f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Mohamedh Fazal

unread,
Jun 5, 2016, 6:08:01 AM6/5/16
to ory-hydra
Very cool. Just in time. I hope to make one for my work, and maybe make a generic one to opensource.


On Saturday, June 4, 2016 at 11:21:39 PM UTC+5, Jan Olszak wrote:
Hi,

I wrote a small example IdP for Hydra. It doesn't do much, but I believe it fully integrates wi    // This would be a concrete type that satisfies datastore.ProjectStore.
    // We embed it here so that our goodProjectStub type has all the methods
    // needed to satisfy datastore.ProjectStore, without having to stub out
    // every method (we might not want to test all of them, or some might be
    // not need to be stubbed.
    *datastore.Projectth Hydra

Jan Olszak

unread,
Jun 5, 2016, 6:34:05 AM6/5/16
to ory-hydra
Awesome!

I thought about making an open source IdP and a library for a resource provider, written in Go.

We should team up!

Aeneas Rekkas

unread,
Jun 5, 2016, 6:52:09 AM6/5/16
to ory-...@googlegroups.com

It would be awesome to see that! Let me know if I can help

--
You received this message because you are subscribed to the Google Groups "ory-hydra" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ory-hydra+...@googlegroups.com.
To post to this group, send email to ory-...@googlegroups.com.

Mohamedh Fazal

unread,
Jun 5, 2016, 7:08:57 AM6/5/16
to ory-hydra
We definitely should!

Jan Olszak

unread,
Jun 5, 2016, 11:08:42 AM6/5/16
to ory-hydra

Hi,

OK, so that's how I see the overall picture:

- RS and IdP are separate services, that have some persistent Storage. 

- RS is out of our scope,  but it needs some kind of an interface library database to wrap Hydra's REST API in Golang


- IdP can be very sophisticated, there are many ways to authorize

- In the first version we should write authorization via user/password and session cookies

- I'm sure everyone wants a different Storage backend, so it needs to be "plugguble"



Proposition of how we could divide the work :

- Mohamedh writes the Hydra Client Library and joins IdP development when finished

- Jan starts IdP development 

- Aeneas finishes Hydra, but reviews IdP and the client library from time to time


Do you agree?




Jan Olszak

unread,
Jun 5, 2016, 11:17:21 AM6/5/16
to ory-hydra
Oh, and I should probably say that I need to make this for my private project, not my work. 

Aeneas Rekkas

unread,
Jun 5, 2016, 11:47:47 AM6/5/16
to ory-...@googlegroups.com
LGTM
--
You received this message because you are subscribed to the Google Groups "ory-hydra" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ory-hydra+...@googlegroups.com.
To post to this group, send email to ory-...@googlegroups.com.

Mohamedh Fazal

unread,
Jun 6, 2016, 6:26:12 AM6/6/16
to ory-hydra
Sounds like a plan

Aeneas Rekkas

unread,
Jun 6, 2016, 7:16:15 AM6/6/16
to Mohamedh Fazal, ory-hydra
However one more thing. I would separate the storages. The resource server should not talk to the hydra store nor to the identity provider store. keep the stores separated! Hydra is low latency, even if it’s HTTP-based it will be faster than searching in a large database with some memcache magic.

Think microservices - separate databases per service!



-- 
You received this message because you are subscribed to the Google Groups "ory-hydra" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ory-hydra+...@googlegroups.com.
To post to this group, send email to ory-...@googlegroups.com.

Jan Olszak

unread,
Jun 6, 2016, 7:32:33 AM6/6/16
to ory-hydra
On Monday, June 6, 2016 at 1:16:15 PM UTC+2, aeneas wrote:
However one more thing. I would separate the storages. The resource server should not talk to the hydra store nor to the identity provider store. keep the stores separated! Hydra is low latency, even if it’s HTTP-based it will be faster than searching in a large database with some memcache magic.

This is a configuration dependent, my image is misleading. You can have separate database for everything.
 
Think microservices - separate databases per service!

You can have separate databases managed by one database backend. This simplifies backups, is cost effective and is easy to manage. 
The fact that RS has it's database in the same backend as Hydra doesn't mean it will affect its performance. 

Aeneas Rekkas

unread,
Jun 6, 2016, 7:54:32 AM6/6/16
to Jan Olszak, ory-hydra
sounds good, I think I misread the image :)


Reply all
Reply to author
Forward
0 new messages