Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SSO from a third server and JWT based REST authorization from the app server #15

Open
ProgramCpp opened this issue Aug 13, 2017 · 11 comments

Comments

@ProgramCpp
Copy link
Contributor

ProgramCpp commented Aug 13, 2017

I would like to use a node server to authenticate users on behalf of apps (on sub domains) running on different node servers. and then authorize the routes using stateless sessions/ JWT.
Scenario: consider A1 and A2 are apps on servers S1 and S2 respectively. S be the authentication server

  1. user accesses A1 and gets authenticated from S.
  2. user performs only authorized operations on A1.
  3. user accesses A2 (could be from a different device) and gets authenticated from S.
  4. user performs only authorized operations on A2.

Note: authentication should be done only by S (validation in one place).

Also, any improvements in the design that fits within cansecurity?

Thanks in advance for the help

@deitch
Copy link
Owner

deitch commented Aug 23, 2017

I still am lost. So there are two services running on two distinct servers:

  • s1.domain.com
  • s2.domain.com

Use goes from browser B to s1.domain.com, gets redirected to auth_server.domain.com (or auth_server.foo.com), gets a JWT, and then goes back and now can access s1.domain.com? Repeat for s2.domain.com?

@ProgramCpp
Copy link
Contributor Author

User goes from browser B to s1.domain.com, gets redirected to auth_server.domain.com, enters credentials, gets a JWT, then goes back and access s1.domain.com.
User goes from browser B to s2.domain.com, gets redirected to auth_server.domain.com and access s2.domain.com (With the JWT already received. User not asked for credentials).
User accesses s1.domain.com or s2.domain.com from browser B2, gets redirected to auth_server.domain.com. 401 is returned.

@deitch
Copy link
Owner

deitch commented Aug 23, 2017

That sounds an awful lot like oauth2. Why not just use it?

@ProgramCpp
Copy link
Contributor Author

ProgramCpp commented Aug 23, 2017

I don't see oauth2 here since the auth_server does not offer any service of its own that s1 or s2 needs to consume. I was just looking for delegating the authentication to a different server. This design could be a overkill and I could just write a node module to consume cansecurity and have authentication in both s1 and s2.

it sounds a lot like SSO/ SAML to me.

@deitch
Copy link
Owner

deitch commented Aug 24, 2017

Yeah, it isn't exactly oauth2, more a variant of some SSO variety. You are saying that when the user goes back to auth_server the second time, auth_server recognizes that the user already has logged in and still has a valid session, so it issues a new JWT valid for s2 (in addition to the one already in place for s1)? Or that the one for s1 is valid for s2?

@ProgramCpp
Copy link
Contributor Author

Yes. The one already issued to s1 is valid for s2 too (new token not needed). s2 is sending the already received token (shared across sub domains, from the same browser) with the request, which the auth_server recognizes to be valid. Probably if the user accesses s1 or s2 from a different Browser. An additional token will be needed (one for both s1 and s2).

@deitch
Copy link
Owner

deitch commented Aug 29, 2017

There are two sides to this here:

  • server
  • client (browser)

cansecurity implements only the server side, i.e. issuing JWT (optional) and validating when accessing a route (including authorization).

What you are saying would work (mostly) out-of-the-box if you ran cansecurity on each of s1, s2, auth_server. Of course, you only would access certain routes on each. We already know how to run it if s2, s2 and auth were just paths on the same server (i.e. same hostname in URL), right?

The only issue then is browser side. You would need to implement it browser side, to capture the 401 from the s1 auth request, go to the auth for login, capture the JWT, and know to submit it (again) to s1 and first-time to s2.

@ProgramCpp
Copy link
Contributor Author

Yes, it will work out-of-the-box if cansecurity is run on both s1 and s2, provided it is not dependent on each other for anything other than SESSIONKEY. We can do away with auth_server (the third server in question) entirely since cansecurity can completely handle issuing JWT and validating them (running on both services).

Should s1 and s2 share only SESSIONKEY to share the JWTs?

And for the browser side, it would be nicer if the X-CS-Auth is part of the cookie and the domain it is applicable to can be configured (to say .domain.com to share it across sub domains). That way, the client need not handle 401 and send the second request for authentication. The first request can carry the cookie (X-CS-Auth) for authorization. Ideally, clients should not authenticate itself again if it is doing SSO. This method would however help only those applications on different sub domains. Not sure if sessions can be maintained by a middleware. I think it can be left to the clients to maintain the JWT in the cookie for sub domains.

@deitch
Copy link
Owner

deitch commented Aug 31, 2017

will work out-of-the-box if cansecurity is run on both s1 and s2, provided it is not dependent on each other for anything other than SESSIONKEY

Correct.

We can do away with auth_server (the third server in question) entirely since cansecurity can completely handle issuing JWT and validating them (running on both services).

Yes, although as it grows, I tend towards the dedicated login server setup. That having been said, in a recent project, we use an API Gateway in front of everything, so it looks like the same server, but there is only one auth_server microservice in the background.

Should s1 and s2 share only SESSIONKEY to share the JWTs?

Yes. I will say, though, that I would like to see a pubkey/privkey option, so that only the auth server needs the private key, and the app servers only need the public key.

And for the browser side, it would be nicer if the X-CS-Auth is part of the cookie and the domain it is applicable to can be configured

That is a nice idea. In a single page app (which originally drove development), we are not restricted to what cookies can do, we have some dynamic control. Go ahead and open a PR with an option to use a cookie with configurable domain.

Anything else to add here?

@deitch
Copy link
Owner

deitch commented Aug 31, 2017

BTW, what are you using this for? Piqued my curiosity.

@ProgramCpp
Copy link
Contributor Author

It is a toy app where a set of people can record texts and another set of people can view them like in a feedback system.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants