i have 2 spring-boot processes. have spring security enabled on both, , i'm using spring security oauth2 sso setup. i'm using eureka , zuul allows calls boot1 call services in boot2. ui using angular rest calls services, , token being used json web token.
this seems work, in ui. requests use authorization header (which contains jwt) , spring security filter in services parse jwt , extracts security context it. part of spring web processing, adds jsessionid value client's cookie.
recently, had spring security on boot1. when calling rest services boot1, end using zuul forward requests boot2, required in rest client include authorization header jwt , worked fine.
however, have added spring security boot2 (using @enableresourceserver annotation) , rest calls fail unless have both authorization header cookie header contains jsessionid value. calls don't fail, return empty values.
i've enabled logging spring security, , validates correctly in boot1. it's going same zuulfilter. there's no activity on boot2.
is there in zuul requires jsessionid value defined in order forward request? or in boot2, expecting jsessionid header value due introduction of spring security filters?
--- update ---
i've stepped through boot1. can see, code in oauth2tokenrelayfilter throwing exception. specifically, method getaccesstoken calling resttemplate.getaccesstoken().getvalue (line 90, version 1.1.0-release) throws userredirectrequiredexception.
so, while tokenrelayfilter has token, it's attempting refresh it. when receives exception, it's throwing badcredentialsexception instead of using what's been defined.
--- update 2 ---
putting breakpoint in oauth2restoperationsconfiguration, making rest calls without jsessionid ends new defaultoauth2clientcontext created, it's trying create session-scoped beans. jsessionid, it's using persisted defaultoauth2clientcontext, have context.
so, possible to, when constructing defaultoauth2clientcontext, see if request contains token , uses it? or this? we're trying move stateless services, , seems hurdle towards this.
this turned out issue client-id values used different parts of system.
looking @ oauth2tokenrelayfilter, attempting refresh token if client-id defined resource server (boot1) matches defined part of token contained within token provided request. in case, true: token defined using same client-id.
that not correct. when update rest client use token, using different client-id when requesting token, request forwarded correctly expected, without need jsessionid. want.
i suspect caused, in end, incorrect use of client-id values components of system.
