Using Jhipster (monolith, oauth2, with registry) forces our users to log-in every once in a while.
After searching a bit, we assume that it's because we have multiple instances of our monolith and sometimes the users get routed to different instances.
So I have 2 questions:
Why does Jhipster implement oauth2 in a stateful way?
How should we handle this, assuming we're staying with the current configuration?
Related
I'm building a small microservice-based webapp using JHipster with JWT authorization. The Architecture is simple, one gateway and two services with repositories. The problem that I had for the last few hours is the communication between the two backend-services.
At first, I tried to find a token on the services themself, but couldn't find it. If I just missed it in all the docs (quite overwhelming when beginning with the full stack :P), I would be happy to revert my changes and use the predefined token.
My second approach was that each service will authorize itself with the gateway at PostConstruct and save the token in memory to use it each API call. It works without a problem, but I find it hard to believe that this functionality is not already programmed in JHipster.
So my question is whether my approach is usual? If neither is true and there are some best-practices for it, I'm also interested in them.
It depends on the use case.
For user requests, a common approach is: the calling service forwards the token it received to the other service without going through the gateway suing #AuthorizedFeignClient.
For background tasks like scheduled jobs, your approach can be applied or you could also issue long life tokens as long as they have limited permissions through roles. This way you don't have to go through gateway.
Keycloak's offline tokens approach could also inspire you.
We are running two restful apis, one with http and the other is with udp.
They are running on premise infrastructure and within next few release, we'd need run them as google container once we dockenize them
Before we put the service up in cloud and all that, we need to implement oauth!
My question is that where to start and how we should approach implementing oauth 2 considering the road map I described?
Truly appreciate any suggestions.
It kind of depends on what you want to use OAuth2 for.
One option is toThere are OAuth2 implementations for most languages (e.g. https://cwiki.apache.org/confluence/display/OLTU/Index)
This allows you to keep your own login/password system.
If you'd rather delegate the auth and identity to a provider like Google, then you just need to implement the OAuth2 dance to get a user's identity from Google, see https://developers.google.com/accounts/docs/OpenIDConnect for more details.
(and when it comes time to use container engine, visit us on IRC #google-containers if you have questions about containers and Google!)
how can i apply spring security for multitenant web application?
My web application has to be supported for multi-tenants i.e http://:/springapp/appollo---uses ldap for authentication
http://:/springapp/fortis----uses local database for authentication
http://:/springapp/manipal---uses oath for authentication
how can i apply spring security so that is supports for all the tenants
It might look trivial, though this is not a simple case...
Basically, all you need to do is to create a (Spring) Filter in your webapp, that will catch all requests, and by the subdomain of the referrer it will decide what authentication method to use (it can be achieved by a simple table in the DB, that will map a subdomain to an enum, e.g. 'oAuth', 'SAML', 'local', etc. This Filter should be placed before any other authentication filter, and as I said , it will technically decide which auth method to use.
I had to tackle this kind of scenario, and the best solution - as far as I think - was to support one authentication method, and then creating a "bridge" to other authentication methods, as needed. For example, the main authentication method is oAuth2.0. Then, in cases where you need other types of authentication, you create "adapters", or "bridges", to the other mechanisms. So if you need to support LocalDB for cusomerB, and AD for customerC, then you adapt from oAuth to localDB or to AD. In my case, I had to support SAML, so I've created a bridge from oAuth to SAML, because it is not trivial for the same Spring-app to support both oAuth and SAML. (Supporting AD and LocalDB from oAuth are much easier, I think.)
How it happens? you wrap your local DB to be an oAuth-provider, so your app will connect to it. and the same for your AD-connector. You have to parse the URL that the user enters, and you get the "tenant". Then you go to your DB, where you map from the tenant to the needed authentication mechanism, and you know what "bridge" to use.
HTH.
Has anyone actually used OAuth2 for SSO within Spring Security 3?
Scenario:
I need my users to be redirected to an OAuth2 URL when they try to access any URL on my site for the first time. Once they are authenticated there, it will redirect them to a URL on my site, where I need to authorize them and create a session so that they will stay authorized on my site until they log out or time out.
I have tried several configurations in Spring Security using custom pre-auth filters, custom user details services, etc., but I cannot get the flow to work properly. I've not attached any code because I've gone through so many possibilities that I'm not even sure what to post.
I'd appreciate any direction anyone can give. Thanks!
OAuth2 isn't intended as an SSO solution. It's primarily about delegating the right to access resources on your behalf to other parties (applications, for example). So if that's not something you need then perhaps you should be looking at a simpler solution.
It's possible to use OAuth2 to allow access to a resource which provides information on your identity, in which case it can be expanded for authentication use. This is how OpenID connect uses it (by adding a userinfo endpoint resource).
You might want to take a look at the UAA project within CloudFoundry which is built on Spring Security OAuth and uses OAuth2 in this way to provide authentication services and to issue access tokens to applications within the system.
This appears to be a somewhat dead question but here are some resources that may prove useful to future searches:
#EnableOAuth2Sso
#EnableOAuth2Resource
Spring Cloud oauth2 SSO sample
Spring oauth2 SSO with a whole bunch of other stuff too
Who is your Oauth2 provider? In a case of some public one like Facebook, Twitter, Google and many others you can take a look at Spring Social project. Even if you use some private provider you can add it very easy (http://blog.springsource.com/2011/03/10/extending-spring-socials-service-provider-framework/, Developing a Netflix Service Provider Implementation section).
Spring Social is designed to cover your main case with some minor difference: by default you must submit a form to start authentication process. I think this difference may be easy customized to feet your needs.
You can play with Spring Social Showcase sample to have an idea about authentication workflow.
I'm currently designing a Service oriented architecture, and actually I'm facing how to design the login system.
What actually I came out with is:
webUI (client that performs several operations on other services)
loginService (stores user credentials)
other services...
Since the WebUI is one of the way to access services it makes sense to me have the login to be a separated service, so also designing access to specific services can be easily implemented.
But I'm not really sure if this is a good approach to design a login system, that most of the times will be accessed by the web interface. It could also be integrated inside the webUI itself, exposing some way to authenticate users trying to access other services directly.... What do you think about this?
I hope that's clear what I'm trying to do, if not please ask me and I'll update this post with the info you need to better understand. Thanks.
A couple of related scenarios:
Actual users authenticate and the application subsequently calls web services on their behalf
A system calls the web services
For 1, you can provide a web login as you suggest. You can then use the UsernameToken profile for web service authentication. Alternatively, you can explore a SAML-based SSO solution depending on your requirements, and send a SAML token to the web service.
Look into an STS for the second.