How often does this occur? What is the result? I assume this is triggering a re-login in the UI? There is no caching on the apiman side. However the tokens issued by keycloak to the apiman UI do have an expiration. You could try logging into the keycloak auth admin UI and increasing the lifespan of the tokens. Any more details you can provide would be great. -Eric On 8/10/2015 8:56 AM, Fadi Abdin wrote: > I keep getting occasional "Token is not active." on they keycloak side > occasionally . its really frustrating , i cant figure out what could > cause this to happen. everything seems correct. > > Is there caching between API Man and Keycloak i can turn off ? Have > anyone seeen this behavior ? > > Thanks, > Fadi > Express.com > > > _______________________________________________ > Apiman-user mailing list > Apiman-user(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/apiman-user > _______________________________________________ Apiman-user mailing list Apiman-user(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/apiman-user

hi all , I get this one too. I don't know if i clicked on some button or link or just error arise from another dimension. *16:06:37,817 INFO* [stdout] (default task-59) Updated plan: PlanBean [organization=OrganizationBean [id=HeavyMetalOrg, name=HeavyMetalOrg, description=The Heavy Metal Universe, createdBy=admin, createdOn=2015-08-12 15:57:02.829, modifiedBy=admin, modifiedOn=2015-08-12 15:57:02.829], id=soundsLikeAPlan, name=soundsLikeAPlan, description=454test, createdBy=admin, createdOn=2015-08-12 15:59:41.355] *16:07:56,984 INFO* [stdout] (default task-6) Getting info for user admin *16:09:27,427 ERROR* [org.keycloak.adapters.BearerTokenRequestAuthenticator] (default task-28) Failed to verify token: org.keycloak.VerificationException: Token is not active. at org.keycloak.RSATokenVerifier.verifyToken(RSATokenVerifier.java:46) [keycloak-core-1.2.0.Final.jar:1.2.0.Final] at org.keycloak.RSATokenVerifier.verifyToken(RSATokenVerifier.java:16) [keycloak-core-1.2.0.Final.jar:1.2.0.Final] at org.keycloak.adapters.BearerTokenRequestAuthenticator.authenticateToken(BearerTokenRequestAuthenticator.java:67) [keycloak-adapter-core-1.2.0.Final.jar:1.2.0.Final] at org.keycloak.adapters.BearerTokenRequestAuthenticator.authenticate(BearerTokenRequestAuthenticator.java:62) [keycloak-adapter-core-1.2.0.Final.jar:1.2.0.Final] at org.keycloak.adapters.RequestAuthenticator.authenticate(RequestAuthenticator.java:45) [keycloak-adapter-core-1.2.0.Final.jar:1.2.0.Final] at org.keycloak.adapters.undertow.AbstractUndertowKeycloakAuthMech.keycloakAuthenticate(AbstractUndertowKeycloakAuthMech.java:114) [keycloak-undertow-adapter-1.2.0.Final.jar:1.2.0.Final] at org.keycloak.adapters.undertow.ServletKeycloakAuthMech.authenticate(ServletKeycloakAuthMech.java:94) [keycloak-undertow-adapter-1.2.0.Final.jar:1.2.0.Final] at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:281) [undertow-core-1.1.0.Final.jar:1.1.0.Final] at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:298) [undertow-core-1.1.0.Final.jar:1.1.0.Final] at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:268) [undertow-core-1.1.0.Final.jar:1.1.0.Final] at io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:131) [undertow-core-1.1.0.Final.jar:1.1.0.Final] at io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:106) [undertow-core-1.1.0.Final.jar:1.1.0.Final] at io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:99) [undertow-core-1.1.0.Final.jar:1.1.0.Final] at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:54) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33) [undertow-core-1.1.0.Final.jar:1.1.0.Final] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final] at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) [undertow-core-1.1.0.Final.jar:1.1.0.Final] at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.1.0.Final.jar:1.1.0.Final] at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:63) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.1.0.Final.jar:1.1.0.Final] at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.1.0.Final.jar:1.1.0.Final] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final] at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final] at org.keycloak.adapters.undertow.ServletPreAuthActionsHandler.handleRequest(ServletPreAuthActionsHandler.java:69) [keycloak-undertow-adapter-1.2.0.Final.jar:1.2.0.Final] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final] at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:261) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:247) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:76) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:166) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] at io.undertow.server.Connectors.executeRootHandler(Connectors.java:197) [undertow-core-1.1.0.Final.jar:1.1.0.Final] at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:759) [undertow-core-1.1.0.Final.jar:1.1.0.Final] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_45] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_45] at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_45] On Tue, Aug 11, 2015 at 5:16 AM, Marc Savy <marc.savy(a)redhat.com <mailto:marc.savy@redhat.com>> wrote: I think this may pertain to the Keycloak OAuth2 token. In which case, I provided Fadi with a version containing additional logging to see if we could track the issue down. It's not an issue I've ever been able to replicate, and we don't fiddle with the token data in any way, so I don't really see how we could affect things. My only suggestions are to ensure that time is accurate on all of the systems (NTP, Chronyd, etc), and I believe this has already been done. On 10/08/2015 18:00, Eric Wittmann wrote: > How often does this occur? What is the result? > > I assume this is triggering a re-login in the UI? > > There is no caching on the apiman side. However the tokens issued by > keycloak to the apiman UI do have an expiration. You could try logging > into the keycloak auth admin UI and increasing the lifespan of the tokens. > > Any more details you can provide would be great. > > -Eric > > On 8/10/2015 8:56 AM, Fadi Abdin wrote: >> I keep getting occasional "Token is not active." on they keycloak side >> occasionally . its really frustrating , i cant figure out what could >> cause this to happen. everything seems correct. >> >> Is there caching between API Man and Keycloak i can turn off ? Have >> anyone seeen this behavior ? >> >> Thanks, >> Fadi >> Express.com >> >> >> _______________________________________________ >> Apiman-user mailing list >> Apiman-user(a)lists.jboss.org <mailto:Apiman-user@lists.jboss.org> >> https://lists.jboss.org/mailman/listinfo/apiman-user >> > _______________________________________________ > Apiman-user mailing list > Apiman-user(a)lists.jboss.org <mailto:Apiman-user@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/apiman-user > _______________________________________________ Apiman-user mailing list Apiman-user(a)lists.jboss.org <mailto:Apiman-user@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/apiman-user _______________________________________________ Apiman-user mailing list Apiman-user(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/apiman-user

Is this something you can reproduce? Or just something that happened once? unfortunately no. just once. What did you experience when this occurred? Did you get sent to the login page? Did you get a blank page? Error in the UI? nothing, just navigating , clicking etc.. no blank page or error in the UI. On Wed, Aug 12, 2015 at 4:36 PM, Eric Wittmann <eric.wittmann(a)redhat.com&gt; wrote: > Is this something you can reproduce? Or just something that happened > once? > > What did you experience when this occurred? Did you get sent to the > login page? Did you get a blank page? Error in the UI? > > -Eric > > On 8/12/2015 3:23 PM, Helio Frota wrote: > >> hi all , >> >> I get this one too. >> >> I don't know if i clicked on some button or link or just error arise >> from another dimension. >> >> *16:06:37,817 INFO* [stdout] (default task-59) Updated plan: PlanBean >> [organization=OrganizationBean [id=HeavyMetalOrg, name=HeavyMetalOrg, >> description=The Heavy Metal Universe, createdBy=admin, >> createdOn=2015-08-12 15:57:02.829, modifiedBy=admin, >> modifiedOn=2015-08-12 15:57:02.829], id=soundsLikeAPlan, >> name=soundsLikeAPlan, description=454test, createdBy=admin, >> createdOn=2015-08-12 15:59:41.355] >> *16:07:56,984 INFO* [stdout] (default task-6) Getting info for user >> admin >> *16:09:27,427 ERROR* >> >> [org.keycloak.adapters.BearerTokenRequestAuthenticator] (default >> task-28) Failed to verify token: org.keycloak.VerificationException: >> Token is not active. >> at >> org.keycloak.RSATokenVerifier.verifyToken(RSATokenVerifier.java:46) >> [keycloak-core-1.2.0.Final.jar:1.2.0.Final] >> at >> org.keycloak.RSATokenVerifier.verifyToken(RSATokenVerifier.java:16) >> [keycloak-core-1.2.0.Final.jar:1.2.0.Final] >> at >> >> org.keycloak.adapters.BearerTokenRequestAuthenticator.authenticateToken(BearerTokenRequestAuthenticator.java:67) >> [keycloak-adapter-core-1.2.0.Final.jar:1.2.0.Final] >> at >> >> org.keycloak.adapters.BearerTokenRequestAuthenticator.authenticate(BearerTokenRequestAuthenticator.java:62) >> [keycloak-adapter-core-1.2.0.Final.jar:1.2.0.Final] >> at >> >> org.keycloak.adapters.RequestAuthenticator.authenticate(RequestAuthenticator.java:45) >> [keycloak-adapter-core-1.2.0.Final.jar:1.2.0.Final] >> at >> >> org.keycloak.adapters.undertow.AbstractUndertowKeycloakAuthMech.keycloakAuthenticate(AbstractUndertowKeycloakAuthMech.java:114) >> [keycloak-undertow-adapter-1.2.0.Final.jar:1.2.0.Final] >> at >> >> org.keycloak.adapters.undertow.ServletKeycloakAuthMech.authenticate(ServletKeycloakAuthMech.java:94) >> [keycloak-undertow-adapter-1.2.0.Final.jar:1.2.0.Final] >> at >> >> io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:281) >> [undertow-core-1.1.0.Final.jar:1.1.0.Final] >> at >> >> io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:298) >> [undertow-core-1.1.0.Final.jar:1.1.0.Final] >> at >> >> io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:268) >> [undertow-core-1.1.0.Final.jar:1.1.0.Final] >> at >> >> io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:131) >> [undertow-core-1.1.0.Final.jar:1.1.0.Final] >> at >> >> io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:106) >> [undertow-core-1.1.0.Final.jar:1.1.0.Final] >> at >> >> io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:99) >> [undertow-core-1.1.0.Final.jar:1.1.0.Final] >> at >> >> io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:54) >> [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >> at >> >> io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33) >> [undertow-core-1.1.0.Final.jar:1.1.0.Final] >> at >> >> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >> [undertow-core-1.1.0.Final.jar:1.1.0.Final] >> at >> >> io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) >> [undertow-core-1.1.0.Final.jar:1.1.0.Final] >> at >> >> io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) >> [undertow-core-1.1.0.Final.jar:1.1.0.Final] >> at >> >> io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:63) >> [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >> at >> >> io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56) >> [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >> at >> >> io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) >> [undertow-core-1.1.0.Final.jar:1.1.0.Final] >> at >> >> io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) >> [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >> at >> >> io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) >> [undertow-core-1.1.0.Final.jar:1.1.0.Final] >> at >> >> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >> [undertow-core-1.1.0.Final.jar:1.1.0.Final] >> at >> >> org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) >> at >> >> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >> [undertow-core-1.1.0.Final.jar:1.1.0.Final] >> at >> >> org.keycloak.adapters.undertow.ServletPreAuthActionsHandler.handleRequest(ServletPreAuthActionsHandler.java:69) >> [keycloak-undertow-adapter-1.2.0.Final.jar:1.2.0.Final] >> at >> >> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >> [undertow-core-1.1.0.Final.jar:1.1.0.Final] >> at >> >> io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:261) >> [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >> at >> >> io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:247) >> [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >> at >> >> io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:76) >> [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >> at >> >> io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:166) >> [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >> at >> io.undertow.server.Connectors.executeRootHandler(Connectors.java:197) >> [undertow-core-1.1.0.Final.jar:1.1.0.Final] >> at >> io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:759) >> [undertow-core-1.1.0.Final.jar:1.1.0.Final] >> at >> >> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) >> [rt.jar:1.8.0_45] >> at >> >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) >> [rt.jar:1.8.0_45] >> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_45] >> >> >> >> >> >> On Tue, Aug 11, 2015 at 5:16 AM, Marc Savy <marc.savy(a)redhat.com >> <mailto:marc.savy@redhat.com>> wrote: >> >> I think this may pertain to the Keycloak OAuth2 token. In which >> case, I >> provided Fadi with a version containing additional logging to see if >> we >> could track the issue down. >> >> It's not an issue I've ever been able to replicate, and we don't >> fiddle >> with the token data in any way, so I don't really see how we could >> affect things. >> >> My only suggestions are to ensure that time is accurate on all of the >> systems (NTP, Chronyd, etc), and I believe this has already been >> done. >> >> On 10/08/2015 18:00, Eric Wittmann wrote: >> > How often does this occur? What is the result? >> > >> > I assume this is triggering a re-login in the UI? >> > >> > There is no caching on the apiman side. However the tokens >> issued by >> > keycloak to the apiman UI do have an expiration. You could try >> logging >> > into the keycloak auth admin UI and increasing the lifespan of >> the tokens. >> > >> > Any more details you can provide would be great. >> > >> > -Eric >> > >> > On 8/10/2015 8:56 AM, Fadi Abdin wrote: >> >> I keep getting occasional "Token is not active." on they >> keycloak side >> >> occasionally . its really frustrating , i cant figure out what >> could >> >> cause this to happen. everything seems correct. >> >> >> >> Is there caching between API Man and Keycloak i can turn off ? >> Have >> >> anyone seeen this behavior ? >> >> >> >> Thanks, >> >> Fadi >> >> Express.com >> >> >> >> >> >> _______________________________________________ >> >> Apiman-user mailing list >> >> Apiman-user(a)lists.jboss.org <mailto:Apiman-user@lists.jboss.org> >> >> https://lists.jboss.org/mailman/listinfo/apiman-user >> >> >> > _______________________________________________ >> > Apiman-user mailing list >> > Apiman-user(a)lists.jboss.org <mailto:Apiman-user@lists.jboss.org> >> > https://lists.jboss.org/mailman/listinfo/apiman-user >> > >> >> _______________________________________________ >> Apiman-user mailing list >> Apiman-user(a)lists.jboss.org <mailto:Apiman-user@lists.jboss.org> >> https://lists.jboss.org/mailman/listinfo/apiman-user >> >> >> >> >> _______________________________________________ >> Apiman-user mailing list >> Apiman-user(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/apiman-user >> >>

In all these cases the UI kept working OK? Did you ever get any sort of failure in the UI? Example: missing data, page load failure, etc? -Eric On 8/12/2015 3:46 PM, Helio Frota wrote: > *16:07:56,984 INFO* [stdout] (default task-6) Getting info for user admin > *16:09:27,427 ERROR* > [org.keycloak.adapters.BearerTokenRequestAuthenticator] (default > task-28) Failed to verify token: org.keycloak. > > almost 2 min of inactivity.. > > but i did a try with more minutes and no errors ... > > *16:36*:09,869 INFO [stdout] (default task-8) Got organization > HeavyMetalOrg: OrganizationBean [id=HeavyMetalOrg, name=HeavyMetalOrg, > description=The Heavy Metal Universe, createdBy=admin, > createdOn=2015-08-12 15:57:02.829, modifiedBy=admin, > modifiedOn=2015-08-12 15:57:02.829] > *16:42*:06,805 INFO [stdout] (default task-9) Getting info for user admin > > > > On Wed, Aug 12, 2015 at 4:40 PM, Helio Frota <00hf11(a)gmail.com > <mailto:00hf11@gmail.com>> wrote: > > Is this something you can reproduce? Or just something that > happened once? > > unfortunately no. just once. > > What did you experience when this occurred? Did you get sent to the > login page? Did you get a blank page? Error in the UI? > > nothing, just navigating , clicking etc.. no blank page or error in > the UI. > > > > > > > > > On Wed, Aug 12, 2015 at 4:36 PM, Eric Wittmann > <eric.wittmann(a)redhat.com <mailto:eric.wittmann@redhat.com>> wrote: > > Is this something you can reproduce? Or just something that > happened once? > > What did you experience when this occurred? Did you get sent to > the login page? Did you get a blank page? Error in the UI? > > -Eric > > On 8/12/2015 3:23 PM, Helio Frota wrote: > > hi all , > > I get this one too. > > I don't know if i clicked on some button or link or just > error arise > from another dimension. > > *16:06:37,817 INFO* [stdout] (default task-59) Updated > plan: PlanBean > [organization=OrganizationBean [id=HeavyMetalOrg, > name=HeavyMetalOrg, > description=The Heavy Metal Universe, createdBy=admin, > createdOn=2015-08-12 15:57:02.829, modifiedBy=admin, > modifiedOn=2015-08-12 15:57:02.829], id=soundsLikeAPlan, > name=soundsLikeAPlan, description=454test, createdBy=admin, > createdOn=2015-08-12 15:59:41.355] > *16:07:56,984 INFO* [stdout] (default task-6) Getting info > for user admin > *16:09:27,427 ERROR* > > [org.keycloak.adapters.BearerTokenRequestAuthenticator] (default > task-28) Failed to verify token: > org.keycloak.VerificationException: > Token is not active. > at > org.keycloak.RSATokenVerifier.verifyToken(RSATokenVerifier.java:46) > [keycloak-core-1.2.0.Final.jar:1.2.0.Final] > at > org.keycloak.RSATokenVerifier.verifyToken(RSATokenVerifier.java:16) > [keycloak-core-1.2.0.Final.jar:1.2.0.Final] > at > org.keycloak.adapters.BearerTokenRequestAuthenticator.authenticateToken(BearerTokenRequestAuthenticator.java:67) > [keycloak-adapter-core-1.2.0.Final.jar:1.2.0.Final] > at > org.keycloak.adapters.BearerTokenRequestAuthenticator.authenticate(BearerTokenRequestAuthenticator.java:62) > [keycloak-adapter-core-1.2.0.Final.jar:1.2.0.Final] > at > org.keycloak.adapters.RequestAuthenticator.authenticate(RequestAuthenticator.java:45) > [keycloak-adapter-core-1.2.0.Final.jar:1.2.0.Final] > at > org.keycloak.adapters.undertow.AbstractUndertowKeycloakAuthMech.keycloakAuthenticate(AbstractUndertowKeycloakAuthMech.java:114) > [keycloak-undertow-adapter-1.2.0.Final.jar:1.2.0.Final] > at > org.keycloak.adapters.undertow.ServletKeycloakAuthMech.authenticate(ServletKeycloakAuthMech.java:94) > [keycloak-undertow-adapter-1.2.0.Final.jar:1.2.0.Final] > at > io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:281) > [undertow-core-1.1.0.Final.jar:1.1.0.Final] > at > io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:298) > [undertow-core-1.1.0.Final.jar:1.1.0.Final] > at > io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:268) > [undertow-core-1.1.0.Final.jar:1.1.0.Final] > at > io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:131) > [undertow-core-1.1.0.Final.jar:1.1.0.Final] > at > io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:106) > [undertow-core-1.1.0.Final.jar:1.1.0.Final] > at > io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:99) > [undertow-core-1.1.0.Final.jar:1.1.0.Final] > at > io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:54) > [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] > at > io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33) > [undertow-core-1.1.0.Final.jar:1.1.0.Final] > at > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > [undertow-core-1.1.0.Final.jar:1.1.0.Final] > at > io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) > [undertow-core-1.1.0.Final.jar:1.1.0.Final] > at > io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) > [undertow-core-1.1.0.Final.jar:1.1.0.Final] > at > io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:63) > [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] > at > io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56) > [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] > at > io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) > [undertow-core-1.1.0.Final.jar:1.1.0.Final] > at > io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) > [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] > at > io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) > [undertow-core-1.1.0.Final.jar:1.1.0.Final] > at > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > [undertow-core-1.1.0.Final.jar:1.1.0.Final] > at > org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > at > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > [undertow-core-1.1.0.Final.jar:1.1.0.Final] > at > org.keycloak.adapters.undertow.ServletPreAuthActionsHandler.handleRequest(ServletPreAuthActionsHandler.java:69) > [keycloak-undertow-adapter-1.2.0.Final.jar:1.2.0.Final] > at > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > [undertow-core-1.1.0.Final.jar:1.1.0.Final] > at > io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:261) > [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] > at > io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:247) > [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] > at > io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:76) > [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] > at > io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:166) > [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] > at > io.undertow.server.Connectors.executeRootHandler(Connectors.java:197) > [undertow-core-1.1.0.Final.jar:1.1.0.Final] > at > io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:759) > [undertow-core-1.1.0.Final.jar:1.1.0.Final] > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > [rt.jar:1.8.0_45] > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > [rt.jar:1.8.0_45] > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_45] > > > > > > On Tue, Aug 11, 2015 at 5:16 AM, Marc Savy > <marc.savy(a)redhat.com <mailto:marc.savy@redhat.com> > <mailto:marc.savy@redhat.com <mailto:marc.savy@redhat.com>>> > wrote: > > I think this may pertain to the Keycloak OAuth2 token. > In which case, I > provided Fadi with a version containing additional > logging to see if we > could track the issue down. > > It's not an issue I've ever been able to replicate, and > we don't fiddle > with the token data in any way, so I don't really see > how we could > affect things. > > My only suggestions are to ensure that time is accurate > on all of the > systems (NTP, Chronyd, etc), and I believe this has > already been done. > > On 10/08/2015 18:00, Eric Wittmann wrote: > > How often does this occur? What is the result? > > > > I assume this is triggering a re-login in the UI? > > > > There is no caching on the apiman side. However the > tokens issued by > > keycloak to the apiman UI do have an expiration. > You could try > logging > > into the keycloak auth admin UI and increasing the > lifespan of > the tokens. > > > > Any more details you can provide would be great. > > > > -Eric > > > > On 8/10/2015 8:56 AM, Fadi Abdin wrote: > >> I keep getting occasional "Token is not active." on > they > keycloak side > >> occasionally . its really frustrating , i cant > figure out what could > >> cause this to happen. everything seems correct. > >> > >> Is there caching between API Man and Keycloak i can > turn off ? Have > >> anyone seeen this behavior ? > >> > >> Thanks, > >> Fadi > >> Express.com > >> > >> > >> _______________________________________________ > >> Apiman-user mailing list > >> Apiman-user(a)lists.jboss.org > <mailto:Apiman-user@lists.jboss.org> > <mailto:Apiman-user@lists.jboss.org > <mailto:Apiman-user@lists.jboss.org>> > >> https://lists.jboss.org/mailman/listinfo/apiman-user > >> > > _______________________________________________ > > Apiman-user mailing list > > Apiman-user(a)lists.jboss.org > <mailto:Apiman-user@lists.jboss.org> > <mailto:Apiman-user@lists.jboss.org > <mailto:Apiman-user@lists.jboss.org>> > > https://lists.jboss.org/mailman/listinfo/apiman-user > > > > _______________________________________________ > Apiman-user mailing list > Apiman-user(a)lists.jboss.org > <mailto:Apiman-user@lists.jboss.org> > <mailto:Apiman-user@lists.jboss.org > <mailto:Apiman-user@lists.jboss.org>> > https://lists.jboss.org/mailman/listinfo/apiman-user > > > > > _______________________________________________ > Apiman-user mailing list > Apiman-user(a)lists.jboss.org <mailto:Apiman-user@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/apiman-user > > > > > > _______________________________________________ > Apiman-user mailing list > Apiman-user(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/apiman-user > _______________________________________________ Apiman-user mailing list Apiman-user(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/apiman-user

In all these cases the UI kept working OK? Yes. Did you ever get any sort of failure in the UI? No. Example: missing data, page load failure, etc? No. nothing, I don't remember if i clicked on some button or link , or just the stack trace arise by doing nothing. Trying to catch this again ( i have no idea how, but trying ) For now, I noticed that from time to time this is executed: GET http://localhost:8080/apimanui/rest/tokenRefresh 200 OK apiman [9:04:28 AM]>> Bearer token successfully refreshed: { "token": "eyJhbG ... long token here", "refreshPeriod": 240 }

OK so everything works but you sometimes see a stack trace. The stack trace is coming from the keycloak auth adapter. As long as everything else still works, I'd be inclined to either ignore it or report it to keycloak. Periodic calls to http://localhost:8080/apimanui/rest/tokenRefresh are expected. This is done to obtain a new auth token that can be used to make authenticated calls to the API Manager REST layer (from the UI). The auth token issued by keycloak expires after 2 minutes. -Eric On 8/13/2015 8:12 AM, Helio Frota wrote: > In all these cases the UI kept working OK? > > Yes. > > Did you ever get any sort of failure in the UI? > > No. > > Example: missing data, page load failure, etc? > > No. nothing, I don't remember if i clicked on some button or link , or > just the stack trace arise by doing nothing. > > Trying to catch this again ( i have no idea how, but trying ) > > For now, I noticed that from time to time this is executed: > > GET http://localhost:8080/apimanui/rest/tokenRefresh > 200 OK > > apiman [9:04:28 AM]>> Bearer token successfully refreshed: { > "token": "eyJhbG ... long token here", > "refreshPeriod": 240 > } > > > > > _______________________________________________ > Apiman-user mailing list > Apiman-user(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/apiman-user > >

Marc / Eric, Thank you for your help in the past , i really appreciate it . but my issue did not get resolved yet . My Application is really simple , i get a token from keycloak and use that token call API MAN services . When the application is fresh installed , this problem does not happened often , but once many users using it and over time , it will start rejecting tokens with the "Token is not active" message . for example if my service is on https://myserver.com/api-gateway/myservice i pass a token like with an access_token parameter https://myserver.com/api-gateway/myservice?access_token=<token value> some time it return a value and some times not . i'm always using a new browser , so its not the cashing. The only way to solve the issue is to restart keycloak/apiman , seems they back in sync . It started a small problem with dev , but now its expanding because our product with the QA people and this escalating .. Is there a way you guys can help us a little more ? is there a paid support ? Thanks, On Tue, Aug 11, 2015 at 4:16 AM, Marc Savy <marc.savy(a)redhat.com <mailto:marc.savy@redhat.com>> wrote: I think this may pertain to the Keycloak OAuth2 token. In which case, I provided Fadi with a version containing additional logging to see if we could track the issue down. It's not an issue I've ever been able to replicate, and we don't fiddle with the token data in any way, so I don't really see how we could affect things. My only suggestions are to ensure that time is accurate on all of the systems (NTP, Chronyd, etc), and I believe this has already been done. On 10/08/2015 18:00, Eric Wittmann wrote: How often does this occur? What is the result? I assume this is triggering a re-login in the UI? There is no caching on the apiman side. However the tokens issued by keycloak to the apiman UI do have an expiration. You could try logging into the keycloak auth admin UI and increasing the lifespan of the tokens. Any more details you can provide would be great. -Eric On 8/10/2015 8:56 AM, Fadi Abdin wrote: I keep getting occasional "Token is not active." on they keycloak side occasionally . its really frustrating , i cant figure out what could cause this to happen. everything seems correct. Is there caching between API Man and Keycloak i can turn off ? Have anyone seeen this behavior ? Thanks, Fadi Express.com _______________________________________________ Apiman-user mailing list Apiman-user(a)lists.jboss.org <mailto:Apiman-user@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/apiman-user _______________________________________________ Apiman-user mailing list Apiman-user(a)lists.jboss.org <mailto:Apiman-user@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/apiman-user

I'm FINALLY ready to write a jira ticket , i think i'm able to identify the what is happening The logs coming in the policy prints the token information, I was surprised to find that sometimes the token being sent is NOT the correct token I sent to APIMan, Example, If I hit a service with a token A , it prints the token B . Token A is my token which is valid and i just got it , But token B is NOT even mine and is expired from yesterday. And this make sense to work after a restart , because it flushes all the tokens and start fresh. If there is a quick way to fix it , flush the tokens or whatever please let me know . I'm going to file a jira ticket , but i need things to work asap because we are in QA now and going to production soon. On Thu, Aug 13, 2015 at 1:20 PM, Eric Wittmann <eric.wittmann(a)redhat.com <mailto:eric.wittmann@redhat.com>> wrote: Fadi - we definitely do want to get to the bottom of this, so are happy to do what we can to help. Hopefully Marc's version of the OAuth2 plugin will help generate some information we can use to track down the problem. Can you please open a JIRA for this issue? And please include as much information as you can, for example: * Version of apiman * Version of OAuth2 plugin * Setup/configuration (example: is Keycloak on a separate server?) * Any other environmental information you think might be relevant Having a JIRA issue will help us keep track of our progress on this issue. -Eric On 8/13/2015 11:52 AM, Fadi Abdin wrote: Marc / Eric, Thank you for your help in the past , i really appreciate it . but my issue did not get resolved yet . My Application is really simple , i get a token from keycloak and use that token call API MAN services . When the application is fresh installed , this problem does not happened often , but once many users using it and over time , it will start rejecting tokens with the "Token is not active" message . for example if my service is on https://myserver.com/api-gateway/myservice i pass a token like with an access_token parameter https://myserver.com/api-gateway/myservice?access_token=<token value> some time it return a value and some times not . i'm always using a new browser , so its not the cashing. The only way to solve the issue is to restart keycloak/apiman , seems they back in sync . It started a small problem with dev , but now its expanding because our product with the QA people and this escalating .. Is there a way you guys can help us a little more ? is there a paid support ? Thanks, On Tue, Aug 11, 2015 at 4:16 AM, Marc Savy <marc.savy(a)redhat.com <mailto:marc.savy@redhat.com> <mailto:marc.savy@redhat.com <mailto:marc.savy@redhat.com>>> wrote: I think this may pertain to the Keycloak OAuth2 token. In which case, I provided Fadi with a version containing additional logging to see if we could track the issue down. It's not an issue I've ever been able to replicate, and we don't fiddle with the token data in any way, so I don't really see how we could affect things. My only suggestions are to ensure that time is accurate on all of the systems (NTP, Chronyd, etc), and I believe this has already been done. On 10/08/2015 18:00, Eric Wittmann wrote: How often does this occur? What is the result? I assume this is triggering a re-login in the UI? There is no caching on the apiman side. However the tokens issued by keycloak to the apiman UI do have an expiration. You could try logging into the keycloak auth admin UI and increasing the lifespan of the tokens. Any more details you can provide would be great. -Eric On 8/10/2015 8:56 AM, Fadi Abdin wrote: I keep getting occasional "Token is not active." on they keycloak side occasionally . its really frustrating , i cant figure out what could cause this to happen. everything seems correct. Is there caching between API Man and Keycloak i can turn off ? Have anyone seeen this behavior ? Thanks, Fadi Express.com _______________________________________________ Apiman-user mailing list Apiman-user(a)lists.jboss.org <mailto:Apiman-user@lists.jboss.org> <mailto:Apiman-user@lists.jboss.org <mailto:Apiman-user@lists.jboss.org>> https://lists.jboss.org/mailman/listinfo/apiman-user _______________________________________________ Apiman-user mailing list Apiman-user(a)lists.jboss.org <mailto:Apiman-user@lists.jboss.org> <mailto:Apiman-user@lists.jboss.org <mailto:Apiman-user@lists.jboss.org>> https://lists.jboss.org/mailman/listinfo/apiman-user

Also, please provide feedback in the JIRA ticket, if you can - https://issues.jboss.org/browse/APIMAN-623 You haven't provided enough detail for us to reconstruct your problem (with regards to using query parameters). On 14/08/2015 21:08, Fadi Abdin wrote: > I was only able to see the problem on the string parameter , but not the > bearer token when i use curl. that might do the trick for me after all > the struggle. > > I'm having another problem with Bearer Token and CORS , thats why i'm > not using it and it works fine with the parameter .. I'll open another > case for this > > On Fri, Aug 14, 2015 at 12:08 PM, Marc Savy <marc.savy(a)redhat.com > <mailto:marc.savy@redhat.com>> wrote: > > Hi Fadi, > > Will be happy to investigate. Could you try another test for me, > please? > > Instead of setting the query parameter access_token, can you please > instead use the Authorization header? This is a bit more resistant > to some weirder forms of caching that might be going on in your > pipeline. > > Authorization: Bearer <token here> > > Do *not* set the access_token query param. > > In cURL you can do this by putting: > > curl -v -H "Authorization: Bearer <token>" <url> > > Regards, > Marc > > On 14/08/2015 16:47, Fadi Abdin wrote: > > I'm FINALLY ready to write a jira ticket , i think i'm able to > identify > the what is happening > > The logs coming in the policy prints the token information, I was > surprised to find that sometimes the token being sent is NOT the > correct > token I sent to APIMan, > > Example, If I hit a service with a token A , it prints the token > B . > Token A is my token which is valid and i just got it , But token > B is > NOT even mine and is expired from yesterday. > > And this make sense to work after a restart , because it flushes > all the > tokens and start fresh. > > If there is a quick way to fix it , flush the tokens or whatever > please > let me know . > I'm going to file a jira ticket , but i need things to work asap > because > we are in QA now and going to production soon. > > > > On Thu, Aug 13, 2015 at 1:20 PM, Eric Wittmann > <eric.wittmann(a)redhat.com <mailto:eric.wittmann@redhat.com> > <mailto:eric.wittmann@redhat.com > > <mailto:eric.wittmann@redhat.com>>> wrote: > > Fadi - we definitely do want to get to the bottom of this, > so are > happy to do what we can to help. > > Hopefully Marc's version of the OAuth2 plugin will help > generate > some information we can use to track down the problem. > > Can you please open a JIRA for this issue? And please > include as > much information as you can, for example: > > * Version of apiman > * Version of OAuth2 plugin > * Setup/configuration (example: is Keycloak on a separate > server?) > * Any other environmental information you think might be > relevant > > Having a JIRA issue will help us keep track of our progress > on this > issue. > > -Eric > > On 8/13/2015 11:52 AM, Fadi Abdin wrote: > > Marc / Eric, > > Thank you for your help in the past , i really > appreciate it . > but my > issue did not get resolved yet . > > My Application is really simple , i get a token from > keycloak > and use > that token call API MAN services . > > When the application is fresh installed , this problem > does not > happened > often , but once many users using it and over time , it > will start > rejecting tokens with the "Token is not active" message . > > for example if my service is on > https://myserver.com/api-gateway/myservice i pass a token like > with an > access_token parameter > > https://myserver.com/api-gateway/myservice?access_token=<token > value> > some time it return a value and some times not . i'm > always > using a new > browser , so its not the cashing. > > The only way to solve the issue is to restart > keycloak/apiman , > seems > they back in sync . > > It started a small problem with dev , but now its > expanding > because our > product with the QA people and this escalating .. Is > there a way you > guys can help us a little more ? is there a paid support > ? > > Thanks, > > > > On Tue, Aug 11, 2015 at 4:16 AM, Marc Savy > <marc.savy(a)redhat.com <mailto:marc.savy@redhat.com> > <mailto:marc.savy@redhat.com <mailto: > marc.savy(a)redhat.com&gt;&gt; > <mailto:marc.savy@redhat.com > <mailto:marc.savy@redhat.com> <mailto:marc.savy@redhat.com > <mailto:marc.savy@redhat.com>>>> wrote: > > I think this may pertain to the Keycloak OAuth2 > token. In > which case, I > provided Fadi with a version containing additional > logging > to see if we > could track the issue down. > > It's not an issue I've ever been able to > replicate, and we > don't fiddle > with the token data in any way, so I don't really > see how > we could > affect things. > > My only suggestions are to ensure that time is > accurate on > all of the > systems (NTP, Chronyd, etc), and I believe this > has already > been done. > > > On 10/08/2015 18:00, Eric Wittmann wrote: > > How often does this occur? What is the result? > > I assume this is triggering a re-login in the > UI? > > There is no caching on the apiman side. > However the tokens > issued by > keycloak to the apiman UI do have an > expiration. You > could try > logging > into the keycloak auth admin UI and increasing > the > lifespan of > the tokens. > > Any more details you can provide would be great. > > -Eric > > On 8/10/2015 8:56 AM, Fadi Abdin wrote: > > I keep getting occasional "Token is not > active." on > they > keycloak side > occasionally . its really frustrating , i > cant > figure out > what could > cause this to happen. everything seems > correct. > > Is there caching between API Man and > Keycloak i can > turn off > ? Have > anyone seeen this behavior ? > > Thanks, > Fadi > Express.com > > > > _______________________________________________ > Apiman-user mailing list > Apiman-user(a)lists.jboss.org <mailto:Apiman-user@lists.jboss.org> > <mailto:Apiman-user@lists.jboss.org > <mailto:Apiman-user@lists.jboss.org>> > <mailto:Apiman-user@lists.jboss.org > <mailto:Apiman-user@lists.jboss.org> > <mailto:Apiman-user@lists.jboss.org > <mailto:Apiman-user@lists.jboss.org>>> > https://lists.jboss.org/mailman/listinfo/apiman-user > > _______________________________________________ > Apiman-user mailing list > Apiman-user(a)lists.jboss.org <mailto:Apiman-user@lists.jboss.org> > <mailto:Apiman-user@lists.jboss.org > <mailto:Apiman-user@lists.jboss.org>> > <mailto:Apiman-user@lists.jboss.org > <mailto:Apiman-user@lists.jboss.org> > <mailto:Apiman-user@lists.jboss.org > <mailto:Apiman-user@lists.jboss.org>>> > https://lists.jboss.org/mailman/listinfo/apiman-user > > > > > > >