search

jhipster / jhipster-experimental-microservices

DON'T USE THIS - old experimental repository
45 stars 23 forks source link

Security in a microservices architecture #3

Closed jdubois closed 8 years ago

jdubois commented 8 years ago

This is a follow-up to the discussion at https://github.com/jhipster/generator-jhipster/issues/2584 as this only concerns microservices (ping @sdoxsee @deepu105 @cbornet ).

To summarize, we have 2 architectures possible:

To be complete, there's a third architecture possible, with replicating the HTTP Session like in this tutorial. Let's not go into details, but replication the HTTP session isn't a good option for us.

As the first scenario is already working, I would like now to focus on the second one:

deepu105 commented 8 years ago

My client did some microservice implementations recently but they used JBoss Fuse, let me look into that and see how they did their security, coz for them security is a very critical thing than features

On Wed, 13 Jan 2016 10:32 pm Julien Dubois notifications@github.com wrote:

This is a follow-up to the discussion at jhipster/generator-jhipster#2584 https://github.com/jhipster/generator-jhipster/issues/2584 as this only concerns microservices (ping @sdoxsee https://github.com/sdoxsee @deepu105 https://github.com/deepu105 @cbornet https://github.com/cbornet ).

To summarize, we have 2 architectures possible:

  • A simple one, with only security at the gateway level: this is quite easy to do, as the proxied URLs are secured by Spring Security. But in this case, only the gateway has the user's security information, and the back-end services have no idea who the user is, or what roles he has.
  • A complex one, with all microservices secured using OAuth2 and JWT

To be complete, there's a third architecture possible, with replicating the HTTP Session like in this tutorial http://spring.io/blog/2015/01/28/the-api-gateway-pattern-angular-js-and-spring-security-part-iv. Let's not go into details, but replication the HTTP session isn't a good option for us.

As the first scenario is already working, I would like now to focus on the second one:

  • We need an external OAuth2 server to authentify users: Spring Security OAuth2 + Spring Boot provide a basic working OAuth2 server, but it lacks a UI, federation, etc. It might be enough for our needs, and it's working well with our technology stack. I'm currently having a look at Keycloak https://github.com/keycloak/keycloak from JBoss, which looks much more advanced. Anyway, we should support any OAuth2 server, so this shouldn't be a blocker issue: let's use the easiest solution, and if it's not good, we can still change it afterwards.
  • Then we need to reference this server in our Gateway and back-end microservices, like in this tutorial https://spring.io/blog/2015/02/03/sso-with-oauth2-angular-js-and-spring-security-part-v, using JWT tokens for the authorization details (for performance reasons). Looks doable.
  • Then the biggest issue with OAuth2 is the UI: it seems like it's not possible to have a clean login/logout page (inside our SPA architecture, of course), and the remember-me token is also not going to work. So from a UI/UX point of view this looks bad, we need to find a "good enough" solution for those.

— Reply to this email directly or view it on GitHub https://github.com/jhipster/jhipster-experimental-microservices/issues/3 .

cbornet commented 8 years ago

For the remember-me, as suggested by @sdoxsee we can probably use a thin proxy to store the access_token & refresh_token (encrypted?) in a CSRF protected session cookie.

sdoxsee commented 8 years ago

@jdubois this sounds good.

a) To use the auth server's login, the SPA could store it's previous state in localStorage (rather than $rootScope currently) before it redirects to the auth server and then reload that state after the redirection back from the auth server. SSO becomes quite easy in this option. You could generate multiple jhipster apps pointing to a single auth server, for example. I'm not sure how remember-me would work here though. WRT session management, there are quite a few options here that need some discussion of their own (e.g. what happens when you log out of a single jhipster app...should all apps get logged out? How does the auth server session affect client sessions? etc.)

b) As for an SPA login, I wonder if we can post credentials to the server and have the server, via a password flow, retrieve tokens directly from the auth server (rather than redirecting to the auth server). That seems fine for the simple case where jhipster provides a vanilla auth server (of course even the vanilla spring-boot auth server would have its own login screen that the jhipster app would bypass via password flow). However, with an SPA login + oauth2 (password flow), I don't think we'll get SSO with other apps (jhipster or otherwise) because there's no session created on the auth server without going through their login screen. Remember-me might work in this non SSO scenario.

pnreddysvu commented 8 years ago

Small clarification. KeyCloak is not a OAuth2 server instead it is a "OpenID Connect" server. OpenID Connect protocol is designed on top of OAuth2 which is futuristic.

Spring OAuth2 is a plain OAuth2 identity server.

Very good resource to understand open connect (and actual Keycloak implementation) is below. https://vimeo.com/113604459

jdubois commented 8 years ago

Thanks @pnreddysvu I didn't know that Keycloak wasn't an OAuth2 server - that's not very clear on their website, and I haven't started testing it. Of course, I don't want to use something else than a true OAuth2 server, so let's stick to Spring Security OAuth2, indeed.

pnreddysvu commented 8 years ago

But OpenID connect is inter-operable standard. All major companies are implementing it. Google, Microsoft etc are behind this standard. OAuth2 has some limitations. To solve that OpenID connect was proposed. Underlying is OAuth2. Though it is not fair to compare, OpenID connect is like JPA and OAuth2 is like Hibernate. If you have time you can go through the video which I mentioned in my previous comment. You will understand why OpenId is better than OAuth2 which is next generation security protocol.

jdubois commented 8 years ago

I have seen maybe people asking for OAuth2 (including my main current client), and I've never been asked for OpenID. And I want to have something that works for as many people as possible (which includes, hopefully, my clients!)

pnreddysvu commented 8 years ago

Please note "OpenID connect" is different from OpenID(1.0 and 2.0).

OpenID Connect was standardized in 2014. It is relatively new. It was aimed to solve OAuth2 limitations. Still people not much aware of the standard.

pnreddysvu commented 8 years ago

https://www.youtube.com/watch?feature=player_embedded&v=Kb56GzQ2pSk

tells why to use OpenID connect instead of OAuth2

sdoxsee commented 8 years ago

Mitreid-connect is an oauth2 server as well as an openid connect server. I imagine keycloak must be both as well. Does keycloak not support, say, password flow?

On Sat, 16 Jan 2016 5:29 am pnreddysvu notifications@github.com wrote:

https://www.youtube.com/watch?feature=player_embedded&v=Kb56GzQ2pSk

tells why to use OpenID connect instead of OAuth2

— Reply to this email directly or view it on GitHub https://github.com/jhipster/jhipster-experimental-microservices/issues/3#issuecomment-172181669 .

pnreddysvu commented 8 years ago

It does provide password flow. But it is again openID connect based. See below http://keycloak.github.io/docs/userguide/keycloak-server/html/direct-access-grants.html

chapter 17.

And also see WARNING not to use password flow.

sdoxsee commented 8 years ago

Ok. Sounds like keycloak IS an oauth2 server as well since password flow is not from the openid connect spec. In fact they reference the oauth2 spec.

On Sat, 16 Jan 2016 10:58 am pnreddysvu notifications@github.com wrote:

It does provide password flow. But it is again openID connect based. See below

http://keycloak.github.io/docs/userguide/keycloak-server/html/direct-access-grants.html

chapter 17.

And also see WARNING not to use password flow.

— Reply to this email directly or view it on GitHub https://github.com/jhipster/jhipster-experimental-microservices/issues/3#issuecomment-172218146 .

pnreddysvu commented 8 years ago

@jdubois basically OAuth2.0 is not meant for authentication though it is used.You can think off once again why to go for OAuth2 if we have better security protocol(OpenID connect) that is again on top of OAuth2

pnreddysvu commented 8 years ago

If you see the response

HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache

{
    "access_token":"2YotnFZFEjr1zCsicMWpAA",
    "token_type":"bearer",
    "expires_in":3600,
    "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
    "id_token":"tGzv3JOkF0XG5Qx2TlKWIA",
    "session-state":"234234-234234-234234"
}

It has new attributes like id_token, session_state etc which you don't get in Spring OAuth2.

pnreddysvu commented 8 years ago

@sdoxsee OpenID connect is based on OAuth2. So keycloak must implement OAuth2. But if you use direct OAuth2 APIs you will not get full feature set provided by KeyCloak. You will get full feature set only if you use OpenID connect.

pnreddysvu commented 8 years ago

https://www.kuppingercole.com/blog/kearns/the-death-and-life-of-a-protocol

to back my point "OAuth2 is not an authentication protocol"

pnreddysvu commented 8 years ago

From the long-time lead author of Oauth, Eran Hammer-Lahav

http://hueniverse.com/2012/07/26/oauth-2-0-and-the-road-to-hell/

deepu105 commented 8 years ago

@pnreddysvu in the same article he refers to Open ID connect to be similar to Oauth in terms of complexity etc :P he seemsto have wriiten this after quitting from the Oauth2 board.

pnreddysvu commented 8 years ago

@deepu105 There are many advantages of OpenID connect when compare to OAuth

1) OpenID connect is authentication protocol where as OAuth2 is not 2) Good fit for all types of clients (native, android, REST server side) etc 3) Inter-operable etc..

I am not familiar with other protocol what he has written later.

pnreddysvu commented 8 years ago

@jdubois I am interested to work on keycloak integration if you are willing to use keycloak as "authentication & user management" module.

To integrate with keycloak we have to do below tasks

1) Generate separate client(angular part) and server(REST part) apps 2) Remove security, user management, login, social login etc code from both client and server apps 3) Secure client and server with keycloak

If it is inline with your micro service architecture, i will take up few tasks.

jdubois commented 8 years ago

@pnreddysvu for me we need to work with any OAuth2 server, and not be tied to a specific one. That's the whole idea of using a standard, and that's also what my current clients are looking for. As Spring Security provides an OAuth2 implementation, which we already use, it's logical that we focus on this. However, as we need to support other OAuth2 servers, Keycloak should also be working.

So, concerning your points:

1) we are already working on that -> see the new options in the entity sub-generator. I'm not sure if there is still work to do here, but you can check this out at #2613 and give us feedback 2) yes this will be done, but only when I migrate this sample repository to make it a Yeoman template. You can also help here, but it's too early at the moment, we are not doing the templates yet. 3) here there might be work to do, but only using Keycloak as an OAuth2 server -> I don't want to have dependencies on Keycloak, hopefully we should be able to have something like https://spring.io/blog/2015/02/03/sso-with-oauth2-angular-js-and-spring-security-part-v

And yes I need help on how to do the login/logout pages -> I would like to stay in the AngularJS application, but it seems that we need to redirect to the OAuth2 server.

pnreddysvu commented 8 years ago

@jdubois thanks for the update.

As per my knowledge, unless you use password flow(which is not recommended) you can't avoid redirect to OAuth2 server.

Password flow will not be ideal for micro services since we have to secure each service. Whatever auth server you use (spring Oauth2, keycloak, UAA etc) you have to have SSO.

Sorry I am not a front end developer to help you in login/logout pages. Infact I am also looking for front end guy to work on keycloak integration.

Anyway personally I am interested in keycloak because it provides security, social login, user registration, user management, group management, multi tenancy, LDAP security, custom themes for each client, High Availability etc which takes care of majority of any project work without single line of code.

So I started working on that. I am happy to collaborate If any community members interested.

deepu105 commented 8 years ago

I can try to do login logout pages, but im not familiar with keyclock and spring oauth server much, so @jdubois can you point me in where to start? On 25 Jan 2016 18:15, "pnreddysvu" notifications@github.com wrote:

@jdubois https://github.com/jdubois thanks for the update.

As per my knowledge, unless you use password flow(which is not recommended) you can't avoid redirect to OAuth2 server.

Password flow will not be ideal for micro services since we have to secure each service. Whatever auth server you use (spring Oauth2, keycloak, UAA etc) you have to have SSO.

Sorry I am not a front end developer to help you in login/logout pages. Infact I am also looking for front end guy to work on keycloak integration.

Anyway personally I am interested in keycloak because it provides security, social login, user registration, user management, group management, multi tenancy, LDAP security, custom themes for each client, High Availability etc which takes care of majority of any project work without single line of code.

So I started working on that. I am happy to collaborate If any community members interested.

— Reply to this email directly or view it on GitHub https://github.com/jhipster/jhipster-experimental-microservices/issues/3#issuecomment-174460478 .

sdoxsee commented 8 years ago

@deepu105 I'm fairly familiar with the various security components be it spring oauth2, angular login redirects, or openid connect (if/when we get there) and would be happy to help you if we can coordinate it. @doxsees on Twitter.

deepu105 commented 8 years ago

@sdoxsee yes please lead the way and we will follow suit :)

pnreddysvu commented 8 years ago

@deepu105 As I mentioned earlier,

1) The main generator has to be split into two apps. 1) client app 2) backend app. 2) Remove login/logout functionality from client app and backend app 3) implement login/logout in auth server.Basically it is an SSO. This can be done in many ways. It needs some more discussion.

As @jdubois pointed the modules will be like below. https://github.com/spring-guides/tut-spring-security-and-angular-js/tree/master/oauth2

This works for all types of auth servers.

jdubois commented 8 years ago

Yes @sdoxsee if you are familiar with this you are most welcome -> have a look at the current code, it's pretty close to the tutorial but it's far away from working. This includes the login/logout pages, I don't know how to handle this -> if you have any proposal...

@pnreddysvu for separating the backend/frontend:

pnreddysvu commented 8 years ago

@jdubois only --skip-client option is provided which generates only backend app. There is no option to generate both frontend and backend apps.

sdoxsee commented 8 years ago

@deepu105 I've got a rough sample project(s) based on jhipster and the spring security tutorial. Let me know what you think.

https://github.com/sdoxsee/jhipster-with-external-authserver

deepu105 commented 8 years ago

Sure ill take a look On 27 Jan 2016 00:19, "Stephen Doxsee" notifications@github.com wrote:

@deepu105 https://github.com/deepu105 I've got a rough sample project(s) based on jhipster and the spring security tutorial. Let me know what you think.

https://github.com/sdoxsee/jhipster-with-external-authserver

— Reply to this email directly or view it on GitHub https://github.com/jhipster/jhipster-experimental-microservices/issues/3#issuecomment-175098700 .

sdoxsee commented 8 years ago

I was able to get the app to remember the previous state after the authentication redirect. For example, try http://localhost:8080/#/settings without being authenticated. It should take you to the authserver and send you back to settings after successful authentication. Still needs much work (e.g. the User returned is pretty bare-bones at the moment). Security-wise, the JWT stays out of the angular app which is better. https://github.com/sdoxsee/jhipster-with-external-authserver

jdubois commented 8 years ago

Hi @sdoxsee this looks very promising but I'm having a very hard time trying to make it work.

I have copied your authserver in this repo (see here) and refactored it a bit, but what I can't understand is:

Can you have a look at this current repo?

sdoxsee commented 8 years ago

Thanks for the feedback @jdubois .

Where do you store your login credentials and authorizations?

I'm just using spring-boot's default "user" but configuring its password in the application.properties security.user.password (see: https://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-security.html)`

As for authorizations, they are only stored in memory for now. As a result, authorizations are lost after each restart of the authserver. There is no consent screen for the app because the client is configured with .autoApprove("openid") in AuthserverApplication.java

How is this supposed to be connected to the gateway? I introduced some of the configuration from the tutorial, but I don't understand how those requests are supposed to work... Do you have to configure Zuul so that the OAuth endpoints are available?

Good question. In my example (or really the spring tutorial example), the ui project acted as the app AND the gateway (sort of). From my understanding of the proposed new architecture, the jhigateway will simply route to the microservices and all apps would make their API calls to the gateway. If that's the case, then the oauth2 roles would be as follows;

jhigateway is THE single resource server meaning that it corresponds to the "resource" project in the tutorial. It receives the access_tokens from the jhipster app1's server when the app wants to make an API call. The authserver stands on its own--granting tokens to client applications that can be used to access resource servers (or, in this case, a single resource server gateway). So, I suppose that there are really 2 Zuuls need as

  1. the ui project in the tutorial needs the @EnableZuulProxy and @EnableOAuth2Sso annotations (corresponding to "app1)
  2. the jhigateway needs @EnableZuulProxy as well to route to the various microservices (almost like "hidden" resources servers)
jdubois commented 8 years ago

Thanks @sdoxsee ! I was expecting your first answers, even if I wasn't sure, so that's OK. Then there is something I didn't understand at all, at the end of your comment: when you say that jhigateway is the resource server! Then I'm not totally sure of what you mean:

Then have you seen this ticket on JJWT? Maybe that would be enough for the backend servers? That would definitely simplify things.

sdoxsee commented 8 years ago

Sorry @jdubois . As I am new to the microservices mindset, I think I misunderstood the architecture. I probably need to sort this out before recommending anything else! So, please correct me if I'm wrong. It sounds like, in oauth2 terms, that the roles are:

I was following the JJWT ticket. I think JWT is great but I think it should be done using oauth2. If the backend services "app1", "app2", etc. are "resource servers", then they are already receiving and authorizing JWTs in my example--there's no need for anything else (if I've understood correctly).

jdubois commented 8 years ago

OK so @sdoxsee we agree:

I'll still work on the JJWT idea, as this would work without OAuth2, so it's a broader solution, and this might also be easier to achieve.

sdoxsee commented 8 years ago

@jdubois sorry for the delay. Was travelling

There is one or several Gateways, which are exposing the OAuth2 authorization server so people can get their token. For me, those Gateways are also resource servers.

Let me rephrase to make sure I understand. We'd generate a gateway app (not unlike the current jhipster monolith). We could generate more gateway apps (these are "client" apps) that an end-user would interact directly with...but all using the same authentication session from the oauth2 auth server. This is like the suite of google clients i mentioned earlier.

I don't think these gateway apps are "resource servers". The angular client would be making api calls through the gateway to the resource servers. The gateway server appears to the angular client as it would to today's cookie session-based jhipster apps (with the exception of authentication). It is the gateway that automagically adds the JWT access tokens to the original angular requests as it relays it on to the REAL resource servers...the microservice RESTful APIs. These would be back-end-only APIs (not UIs...although i did read this thread https://github.com/jhipster/jhipster-experimental-microservices/issues/6)

Those Gateways are front-ends exposing various applications (like app1) which are resource servers, and which get security info from the Gateways using a JWT token.

I think I understand this and agree. Yes, the resources servers (back-end-only @EnableResourceServer apps) get their security info relayed to them via the gateway (Zuul) as "JWT access tokens" that the gateway obtained from the oauth2 authorization server.

I'll still work on the JJWT idea, as this would work without OAuth2, so it's a broader solution, and this might also be easier to achieve.

The JWT/authserver/resource server/SSO functionality with spring security oauth2 is built right in and happens almost automatically (from a coding perspective). As nice as JJWT sounds for working with JWTs, I'd rather go "all in" with oauth2 spring security rather than "rolling our own" support and provide multiple yeoman options in this regard. I believe OAuth2 is the way to do microservices and it seems simpler (IMO) to implement (just leverage the power of @EnableOAuth2Resource, @EnableOAuth2Sso, etc. without other custom code). With that said, I'm unfamiliar with discovery and registration with microservices so I'm a little unsure about how to do that at the moment. If the resource servers were explicitly declared in the gateway application.yml then it should work like in my example...although discovery and registration is the goal.

@william-tran has a nice talk about microservices and security https://spring.io/blog/2015/10/19/springone2gx-2015-replay-securing-microservices-with-spring-cloud-security (minus the eureka part)

jdubois commented 8 years ago

I agree with you @sdoxsee but unfortunately I've spent days trying to make this work, and I just couldn't... And I've been coding this kind of things for years! I've just tried JJWT and I had the thing working without any surprise... So at the moment I'm not going to spend more time with the JWT token provided by Spring Security OAuth. Then, of course I want to have OAuth authentication working, and there are a few points I want to make:

william-tran commented 8 years ago

Sorry I'm on holiday for the next couple of weeks, I'd definitely like to spend some time to understand the difficulties you're running into @jdubois and offer my two cents. All I can say is that a gateway can do both in terms of managing an authcode flow and storing the token in session, or as a resource server expecting a token in the header for API calls. It depends on the appropriateness of using session (eg for a browser based UI) or direct API calls with token in header and without a session (eg native mobile app).

sdoxsee commented 8 years ago

@jdubois I hear you about it seeming difficult to setup. I've been finding the same thing. @william-tran is pretty close (minus the angular client and zuul proxy. See: https://github.com/william-tran/microservice-security/tree/feature/spring-cloud-services). I imagine I'm not too far off from being able to do it.

The gateway would also be a resource server. At the moment, the gateway is itself a JHipster application, and that's important that it can do more than just routing requests. Indeed, I'm not sure this works well with OAuth2 in our architecture, and that could be my original problem.

If the gateway backend is designed to be a "resource server" it's probably intended to be used by other applications as well. If that's the case, it probably shouldn't be part of the gateway but rather it's own resource server (i.e. microservice(s)). If the backend of the gateway isn't needed elsewhere, it probably doesn't need to be a resource server but a simple API (just like the session-based non-oauth2 options in today's jhipster monolith).

I don't like to have JWT only when I use OAuth2, and they are coupled with Spring Security OAuth2. The good thing with JJWT is that I can have other authentication mechanisms than OAuth2, and still use JWT for my microservices

I don't like coupling either. It should be noted, however, that just because you use spring security oauth2 on your gateway doesn't mean you need to use it on your resource servers (or microservices) as well. That's the nice thing about JWT. It's just JSON. The advantage of using spring security oauth2 everywhere is that, when it's finally configured properly, that it should save on a lot of boiler-plate code...and, of course, it's easier to support one great way of doing things than multiple ways.

Should I continue investigating this? I still think it's the way to go.

jdubois commented 8 years ago

Stephen, yes I like your option better, so if it's working it would be great. And today we have 4 security options in the monolith application, so for the microservices we could have 2 options. Le 3 févr. 2016 1:35 AM, "Stephen Doxsee" notifications@github.com a écrit :

@jdubois https://github.com/jdubois I hear you about it seeming difficult to setup. I've been finding the same thing. @william-tran https://github.com/william-tran is pretty close (minus the angular client and zuul proxy. See: https://github.com/william-tran/microservice-security/tree/feature/spring-cloud-services). I imagine I'm not too far off from being able to do it.

The gateway would also be a resource server. At the moment, the gateway is itself a JHipster application, and that's important that it can do more than just routing requests. Indeed, I'm not sure this works well with OAuth2 in our architecture, and that could be my original problem.

If the gateway backend is designed to be a "resource server" it's probably intended to be used by other applications as well. If that's the case, it probably shouldn't be part of the gateway but rather it's own resource server (i.e. microservice(s)). If the backend of the gateway isn't needed elsewhere, it probably doesn't need to be a resource server but a simple API (just like the session-based non-oauth2 options in today's jhipster monolith).

I don't like to have JWT only when I use OAuth2, and they are coupled with Spring Security OAuth2. The good thing with JJWT is that I can have other authentication mechanisms than OAuth2, and still use JWT for my microservices

I don't like coupling either. It should be noted, however, that just because you use spring security oauth2 on your gateway doesn't mean you need to use it on your resource servers (or microservices) as well. That's the nice thing about JWT. It's just JSON. The advantage of using spring security oauth2 everywhere is that, when it's finally configured properly, that it should save on a lot of boiler-plate code...and, of course, it's easier to support one great way of doing things than multiple ways.

Should I continue investigating this? I still think it's the way to go.

— Reply to this email directly or view it on GitHub https://github.com/jhipster/jhipster-experimental-microservices/issues/3#issuecomment-178915005 .

sdoxsee commented 8 years ago

Still some work to do here but I've got jhipster + microservices up and running with eureka discovery and oauth2 (but also OpenID Connect via cloudfoundry's uaa)

Let me know what you think: https://github.com/sdoxsee/jhipster-openid-connect-microservices

jdubois commented 8 years ago

Hi @sdoxsee that's great news! I'll definitely check this out tomorrow

jdubois commented 8 years ago

@sdoxsee I didn't you could package UAA like that! Last time I check it was quite complicated to set up, that's great news.

jdubois commented 8 years ago

@sdoxsee I've ran it and looked at the code and this is very very cool! What we would need to do:

Would that be fine with you?

sdoxsee commented 8 years ago

@jdubois Glad you found it cool!

Have our own "openid server", like the JHipster registry -> can we create a "JHipster OpenID Server" which is a copy of your UAA server? Do you want to do it, so you are still the author? We would just need to "jhispterize" it, so it starts like a usual JHipster application, etc... And maybe register it with Eureka?

Sounds good. I'd prefer to let someone on the jhipster core team "jhipsterize" it as I'm short on time these days but I'm happy to answer any questions or be part of discussions about it. Also, be sure to call it "OpenID Connect" as opposed to "OpenID" since they are totally different specifications and "OpenID" doesn't build on OAuth2 at all.

Move your code to JHipster templates -> that means that when using microservices, you would have a question for authentication with 2 answers: either "JWT" (the current solution based on JJWT) or "OpenID" (your current solution)

Great! Again, I'd prefer if someone with more yeoman skills could do that but I'm happy to review or discuss. Although, if no one steps up to do it I could try to get to it eventually.

jdubois commented 8 years ago

@sdoxsee I have started our OpenID Connect server at https://github.com/jhipster/jhipster-openid-connect

sdoxsee commented 8 years ago

Great start @jdubois. I'm not very familiar with uaa in particular but I'm confident its configuration (users, roles/scopes) will take clear shape as this moves forward. Uaa currently stores the user information, not the gateway apps. I'm not sure whether or not we should break out the account/user-management UI in jhipster into its own gateway app (like https://myaccount.google.com/) with proxies to the SCIM endpoints on uaa for creating/updating/deleting (https://github.com/cloudfoundry/uaa/blob/master/docs/UAA-APIs.rst#user-account-management-apis) users and their roles/scopes. For admins, they'd probably like a UI to configure scopes for users not unlike what the user management page does now. Another google example: If I change my password, I'm not just changing my gmail password but rather my google password for all my google "gateway" apps (youtube, drive, calendar, etc.). What's seems clear to me is that for microservices, the user information is not stored in the gateway's db but somewhere else so that it's not duplicated with every gateway and user information stays with the service that handles user stuff (e.g. authentication). Are we ok storing user account info in uaa only? The services that need user info can get it with a JWT like this: https://github.com/william-tran/microservice-security/blob/feature/spring-cloud-services/microsec-order-service/src/main/java/microsec/freddysbbq/order/CustomerOrderController.java#L72

jdubois commented 8 years ago

Yes you are correct, with your solution we shouldn't have user management code in the gateway. That should be easy, we are already making a new switch to remove this code for the microservices applications.

sdoxsee commented 8 years ago

Great!