I see. For this use case you actually need to follow the redirect. So you have to just go with the flow (I think).
I'm not even sure you can hide this from the user without writing code in the browser - it's the browser that has the session with the auth server (if there is one).
So a pre-auth filter isn't such a great idea after all
not good :worried:
since I already have spring-session working between the two
Maybe that saves your bacon then
but the problem is that the authenticated user isn't a oauth2 user, which means I cannot relay the token
You know the user, but he hasn't got a token yet?
yes
How did you identify/authenticate him?
i log into the auth server, and by sharing the session via spring-session I'm automagically logged into the other app on refresh
making shure they both have the same custom userDetails pojo
in both apps
OK, so if there is an authenticated user you know who it is.
yes
There is still the scenario that he didn't yet authenticate with the auth server
yes
the problem is that I need to at checkout get the users customer details, which are in the auth server via a OAuth2RestTemplate
OK, so you just need to send the cookie when you ask for an auth code.
And if there are any exceptions, you can't pre-authenticate.
I think the
OAuth2RestTemplate can do this. I just don't think that feature gets used much outside tests.
so if I use the OAuth2RestTemplate but add the SESSION cookie to the request, it knows it's logged in and then the restTemplate stores the accessToken?
You might be a step ahead there
But something like that.
I need to refresh my memory
(Twiddling thumbs waiting for Eclipse to finish spinning)
I've created this gist, with what I've got so far https://gist.github.com/leon/182f2a221341411f7d1a
Where did the
OAuth2RestTemplate come from?
I have a nervous feeling about shared state between your auth server and all the little client apps (assuming there might actually be more than one).
It is probably the one that gets created via @EnableOAuthSso
Right.
me 2
I'd rather not share the session state between the apps, but as usual I'm trying to grant all the customers wishes :)
So unless you want all client apps to share a token, then sharing a session with the auth server is bad. If you don't mind sharing, maybe you can still be careful and not corrupt each other's state.
I'd rather just force login at the checkout and be done with it. but they really want the auth bar to be visible across all apps :(
This much shared state seems risky. Maybe you ought to look into the client-side implementation?
The question is how would you implement it, I've got a webshop, a portal and more apps coming. and a couple of resource servers both in spring and in .net
You need a bit of Javascript fu
And that code gets shared between all the UIs.
The front end apps webshop, portal and wordpress need to have the same user logged into all of them, and when he / she logs out it should logout of all apps
so it's more of a CAS solution I'm guessing
Logout is a whole other ball of wax
:)
CAS has all the same "features"
You don't get a free lunch
I would probably find myself stuck with the .net apps instead there
Because they are fat clients? No Javascript?
at the moment everything is turning out great except the unified login experience
the portal is angular only, the webshop is part spring part angular because of SEO aspects
Fat clients require a different approach anyway (auth code flow makes no sense, Spring Session is never going to help)
Above you said the resource server was .net, not the client.
the portal gets redirected to the auth server and since it has auto approve, you get logged in straight away
So maybe it's not an issue
You only get logged in straight away if you already have a session with the auth server though
I'm in charge of all the UI apps, the .net apps are data only apps returning data from legacy systems
I thought we were trying to avoid going to the auth server if the user is not authenticated there?
I've implemented remember me functionality with the authserver, so you are logged in the for as long as that cookie exists
that only applies to the webshop
in the portal you are always logged in
I'm going to have a stab at sending a request to the authserver including the session cookie, and if the user is logged in, I can redirect the webshop to /login which will force it to login, thus getting the auth token
You don't even need an
OAuth2RestTemplate to do that (send a cookie and look at the result)
so a normal RestTemplate, and then append the cookie, check if it isn't a 401, and redirect to /login
that seems like a much better solution, even though they are sharing session state
It depends on the implementation of the auth server
I don't know why you need to go to /login (assuming that's a UI)
I've created a /authenticated endpoint that is behind the normal security firewall
So you just need to send the cookie to that endpoint and see what it says, right?
it returns the @AuthenticatedPricipal email
yes
I'll give it a go :)
thanks for the help, it's great to have someone to discuss the inner workings :+1:
No problem
I'll be a spring cloud guru after this project :)