I have a Zuul Proxy that host behind it all Micro services including UI and Authorization servers .
All are part of spring cloud.
I tried to start a second Authorization Servers but that lead to the below errors
2017-11-17 08:07:47.146 INFO 9652 --- [http-nio-9191-exec-2] o.s.s.o.p.token.store.JdbcTokenStore : Failed to find access token for token 08fa5f86-4bbd-4e5b-818b-a79730232f30
2017-11-17 08:07:47.146 DEBUG 9652 --- [http-nio-9191-exec-2] p.a.OAuth2AuthenticationProcessingFilter : Authentication request failed: error="invalid_token", error_description="Invalid access token: 08fa5f86-4bbd-4e5b-818b-a79730232f30"
2017-11-17 08:07:47.147 DEBUG 9652 --- [http-nio-9191-exec-2] s.s.o.p.e.DefaultOAuth2ExceptionRenderer : Written [error="invalid_token", error_description="Invalid access token: 08fa5f86-4bbd-4e5b-818b-a79730232f30"] as "application/json;charset=UTF-8" using [org.springframework.http.converter.json.MappingJackson2HttpMessageConverter#3c3df936]
also
2017-11-17 07:39:51.151 DEBUG 9652 --- [http-nio-9191-exec-3] o.s.s.o.provider.endpoint.TokenEndpoint : Clearing scope of incoming token request
2017-11-17 07:39:51.178 DEBUG 9652 --- [http-nio-9191-exec-3] .s.s.o.p.c.AuthorizationCodeTokenGranter : Getting access token for: acme
2017-11-17 07:39:51.204 INFO 9652 --- [http-nio-9191-exec-3] o.s.s.o.provider.endpoint.TokenEndpoint : Handling error: InvalidGrantException, Invalid authorization code: Pb3JKA
2017-11-17 07:40:04.797 DEBUG 9652 --- [http-nio-9191-exec-4] .s.o.p.e.FrameworkEndpointHandlerMapping : Looking up handler method for path /oauth/token
2017-11-17 07:40:04.797 DEBUG 9652 --- [http-nio-9191-exec-4] .s.o.p.e.FrameworkEndpointHandlerMapping : Returning handler method [public org.springframework.http.ResponseEntity<org.springframework.security.oauth2.common.OAuth2AccessToken> org.springframework.security.oauth2.provider.endpoint.TokenEndpoint.postAccessToken(java.security.Principal,java.util.Map<java.lang.String, java.lang.String>) throws org.springframework.web.HttpRequestMethodNotSupportedException]
2017-11-17 07:40:04.850 DEBUG 9652 --- [http-nio-9191-exec-4] o.s.s.o.provider.endpoint.TokenEndpoint : Clearing scope of incoming token request
My conclusion was I need to have a shared session management between both authorization servers like spring session even though I am using the same jdbctoken database back end.
I could not find any sample or any one talking about this so is this correct or it should work without having a shared session.
It turned out that yes , shared session is needed like spring session , my first attempt did not work because I had mixed configuration between both servers.
After that just enabling shared session management, it all worked perfectly
Related
I am running keycloak 19.0.2 in dev mode. When trying to login to microsoft from keycloak (SSO) using the oauth2 flow, I get 502 error in the browser on the callback to keycloak. The code param has a strange value also.
I believe it has something to do with user permissions, but I can clearly see I have defined them.
The callback to the keycloak server throws a 502 error and has strange values in the code params.
The keycloak server errors with the following logs:
2022-10-17 13:08:46,517 ERROR
[org.keycloak.broker.oidc.AbstractOAuth2IdentityProvider] (executor-thread-42)
Failed to make identity provider oauth callback:
org.keycloak.broker.provider.IdentityBrokerException: Could not obtain user profile
from Microsoft Graph
2022-10-17 13:08:46,542 WARN [org.keycloak.events] (executor-thread-42)
type=IDENTITY_PROVIDER_LOGIN_ERROR, realmId=8ca06b23-d544-4464-a3bf-448be5308802,
clientId=recruit-api, userId=null, ipAddress=127.0.0.1,
error=identity_provider_login_failure, code_id=62aaf7bf-9c08-4c88-a7c3-e6f7af282de1,
authSessionParentId=62aaf7bf-9c08-4c88-a7c3-e6f7af282de1,
authSessionTabId=WjArYJ99WyM
I had configured the keycloak under the user federation settings as kerberos.
I had also entered the realm ,service principal and the keytab file directory as stated .
But I get the issue as : Kerberos is not set up . You cannot login
In firefox I has enabled SPNEGO as per the below docs :
http://www.microhowto.info/howto/configure_firefox_to_authenticate_using_spnego_and_kerberos.html
I am attaching from the log snippet :
2021-06-30 11:43:31,234 DEBUG [org.keycloak.authentication.AuthenticationSelectionResolver] (default task-1) Selections when trying execution 'auth-spnego' : [ authSelection - auth-spnego]
2021-06-30 11:43:31,234 DEBUG [org.keycloak.authentication.DefaultAuthenticationFlow] (default task-1) invoke authenticator.authenticate: auth-spnego
2021-06-30 11:43:31,235 TRACE [org.keycloak.authentication.authenticators.browser.SpnegoAuthenticator] (default task-1) Sending back WWW-Authenticate: Negotiate
Reference to the same issue :
https://marc.info/?l=keycloak-user&m=154803677131797&w=2
Do consider to help us with the concrete solution .
Thanks in advance !
I am using the wso2 sample apps (saml2-web-app-pickup-dispatch and saml2-web-app-pickup-manager) to test single sign on through WSO2 identity server version 5.10.0
The deployment is fine and on clicking the application's login, it redirects to the WSO2 login page successfully.
User logs in successfully but receives error below.
HTTP Status 500 – Internal Server Error
Type Exception Report
Message SAML2 Response Issuer verification failed
Description The server encountered an unexpected condition that prevented it from fulfilling the request.
Exception
org.wso2.carbon.identity.sso.agent.exception.SSOAgentException: SAML2 Response Issuer verification failed
org.wso2.carbon.identity.sso.agent.saml.SAML2SSOManager.processSSOResponse(SAML2SSOManager.java:569)
org.wso2.carbon.identity.sso.agent.saml.SAML2SSOManager.processSSOResponse(SAML2SSOManager.java:525)
org.wso2.carbon.identity.sso.agent.saml.SAML2SSOManager.processResponse(SAML2SSOManager.java:358)
org.wso2.carbon.identity.sso.agent.SAML2SSOAgentFilter.doFilter(SAML2SSOAgentFilter.java:98)
Note The full stack trace of the root cause is available in the server logs.
Apache Tomcat/8.5.53
Logs from the server
TID: [-1234] [2020-04-25 19:16:55,881] [7e977cfd-8304-44ba-ab4f-4644baff988e] INFO {AUDIT_LOG} -
Initiator : wickrema | Action : Login | Target : ApplicationAuthenticationFramework |
Data : {
"ContextIdentifier" : "51f93b05-68cf-4bf4-b62b-51e3e2502889",
"AuthenticatedUser" : "wickrema",
"AuthenticatedUserTenantDomain" : "carbon.super",
"ServiceProviderName" : "saml2-web-app-pickup-dispatch",
"RequestType" : "samlsso",
"RelyingParty" : "saml2-web-app-pickup-dispatch.com",
"AuthenticatedIdPs" : "eyJ0eXAiOiJKV1QiLCAiYWxnIjoibm9uZSJ9.eyJpc3MiOiJ3c28yIiwiZXhwIjoxNTg3ODMxNDE1ODA0MzAwMCwiaWF0IjoxNTg3ODMxNDE1ODA0LCJpZHBzIjpbeyJpZHAiOiJMT0NBTCIsImF1dGhlbnRpY2F0b3IiOiJCYXNpY0F1dGhlbnRpY2F0b3IifV19."
} | Result : Success
Your Service Provider application(Pickup-Dispatch) is trying to verify if the received SAML response is issued by the expected SAML Identity Provider. WSO2 includes its ID in the SAML response's <saml:Issuer> tag.
Your application has a pre-configured entity ID for WSO2 in the saml2-web-app-pickup-dispatch.com/WEB-INF/classes/sso.properties file as below.
SAML2.IdPEntityId=localhost
Likewise, WSO2 IS populates its SAML response's issuer with the value you've configured in the Resident Identity Provider's Home Realm Identifier.
But you can override the Home realm identifier with the IdP Entity ID Alias of your Service Provider SAML configurations as below.
Bottom line, the Issuer ID of the SAML response should be the same as what you've configured in the Application as the IdP Entity ID.
Change either value to make them the same.
Code for your reference
We are developing a Boot-Admin dashboard using the codecentric provided library of spring-boot-admin-server version 1.4.5
Some of the applications are registering itself with the server via Eureka, and some directly using the spring-boot-admin-starter-client version 1.4.5.
All components are deployed on a PCF environment and are communication over HTTPS. In either ways, the applications though are able to register themselves with the admin sever but are showing up as OFFLINE only. There are no errors reported in the logs for any of the components viz. admin-server, admin-client, eureka-server, eureka-client.
However the only application showing as Up is the admin server itself.
The application properties for spring-boot-admin-client app to run in PCF is:
spring:
application:
name: bootadmin-ms-charlie
boot:
admin:
url: https://bootadmin-dashboard.abc.intl.com
ssl:
trust_store:
path: classpath:ssl/sslcacert.jks
password: a-password
As the result is same for both methods of registration, I've skipped putting the config here for apps registering via Eureka path to keep it simple.
The same is working perfectly fine locally, where the admin dashboard shows all the applications as expected.
Is there any configuration that needs to be done in specific to Cloud Foundry?
Or any obvious mistake that I might have made?
Any suggestions are most welcome.
---EDIT---
Here are the logs from SBA server showing that the communication between server and client is working okay. If these logs give any indication of an error, please point out.
OUT 2017-01-23 05:15:15.139 DEBUG 10 --- [nio-8080-exec-1] o.s.web.servlet.DispatcherServlet : DispatcherServlet with name 'dispatcherServlet' processing POST request for [/api/applications]
OUT 2017-01-23 05:15:15.151 DEBUG 10 --- [nio-8080-exec-1] m.m.a.RequestResponseBodyMethodProcessor : Read [class de.codecentric.boot.admin.model.Application] as "application/json;charset=UTF-8" with [org.springframework.http.converter.json.MappingJackson2HttpMessageConverter#7df33a9f]
OUT 2017-01-23 05:15:15.163 DEBUG 10 --- [nio-8080-exec-1] o.s.w.s.m.m.a.HttpEntityMethodProcessor : Written [Application [id=3805ee6a, name=bootadmin-ms-charlie, managementUrl=http://23fcf304-82d6-44cd-7fce-2a5027de9f21:8080, healthUrl=http://23fcf304-82d6-44cd-7fce-2a5027de9f21:8080/health, serviceUrl=http://23fcf304-82d6-44cd-7fce-2a5027de9f21:8080]] as "application/json" using [org.springframework.http.converter.json.MappingJackson2HttpMessageConverter#7df33a9f]
OUT 2017-01-23 05:15:15.166 DEBUG 10 --- [nio-8080-exec-1] o.s.web.servlet.DispatcherServlet : Null ModelAndView returned to DispatcherServlet with name 'dispatcherServlet': assuming HandlerAdapter completed request handling
OUT 2017-01-23 05:15:15.166 DEBUG 10 --- [nio-8080-exec-1] o.s.web.servlet.DispatcherServlet : Successfully completed request
OUT bootadmin-dashboard.abc-intl.com - [23/01/2017:05:15:15.140 +0000] "POST /api/applications HTTP/1.1" 201 302 308 "-" "Java/1.8.0_121" 60.16.25.20:43224 x_forwarded_for:"10.10.10.10" x_forwarded_proto:"https" vcap_request_id:a40159e4-543f-40e0-627e-e8f1e7688b99 response_time:0.034164523 app_id:adcc8a33-83f4-448d-9ae2-bf2a2b16ea72
OUT 2017-01-23 05:15:18.719 DEBUG 10 --- [ updateTask1] o.s.web.client.RestTemplate : Created GET request for "http://23fcf304-82d6-44cd-7fce-2a5027de9f21:8080/health"
OUT 2017-01-23 05:15:18.722 DEBUG 10 --- [ updateTask1] o.s.web.client.RestTemplate : Setting request Accept header to [application/json, application/*+json]
The logs from client are all clean. It throws warning of "Failed to refister" only when the server is down.
Based upon the discussion on https://github.com/codecentric/spring-boot-admin/issues/399 it has been found out that below properties are vital for SBA clients to work with Dashboard on Cloud Foundry or container based architecture:
spring:
boot:
admin:
client:
management-url: <complete management-url for the client>
health-url: <complete health endpoint url for the client>
service-url: <complete root/service url for the client>
This is due to the fact that, when a client registers itself with the
SBA server it uses the runC container ID to form its service url. Such url is not valid for the Cloud Foundry router. That results in failure of communication between SBA dashboard and the client later on, causing it to show as OFFLINE.
The other approach can be to go ahead with container IPs, using spring.boot.admin.client.prefer-ip=true. That would list all containers/CF instacnes on SBA but not give a clear picture of overall health of the complete app from a site/AZ. Also direct connection to containers is never encouraged in CF as per the principles of cloud-native app and 12-factors.
We are currently trying to deploy CAS 4.0.1 on a JBoss EAP 6.3.0 server.
The login webflow was customised in order to redirect to a specific login form depending on the service calling CAS for authentication. Depending on these forms, we use specific authentication handlers, and a specific Credential model. Besides that, the configuration is rather standard.
At the moment, we are experiencing the following issue: when a user attempts to access a service secured by CAS, he is correctly redirected to the portal, and the expected login view is rendered ; upon successful login, the Service Ticket is delivered to the authentication filter on the service side (standard j_spring_cas_security_check), which then validates it successfully against CAS' ticket registry. We see in the logs that CAS is rendering the cas2ServiceSuccessView ; however, instead of delivering the expected XML response, the user is redirected to the login form.
We then confirmed that we were in fact getting a 404 error after the cas2ServiceSuccessView... Any idea what could trigger such behaviour/what we could have done wrong ?
Note that we are getting the same error regardless of how we call CAS for the ST validation: whether it is manually through /serviceValidate?ticket=ST-YYY&service=XXX, or via the /j_spring_cas_security_check on the service side...
Edit: we have the same behaviour running CAS on Tomcat 7.
Thanks in advance.
Below the debug logs that we are getting:
08:54:10,806 DEBUG [org.springframework.web.servlet.DispatcherServlet] (http-/0.0.0.0:8080-7) Last-Modified value for [/cas/serviceValidate] is: -1
08:54:10,809 INFO [org.perf4j.TimingLogger] (http-/0.0.0.0:8080-7) start[1433314450807] time[2] tag[VALIDATE_SERVICE_TICKET]
08:54:10,810 INFO [com.github.inspektr.audit.support.Slf4jLoggingAuditTrailManager] (http-/0.0.0.0:8080-7) Audit trail record BEGIN
=============================================================
WHO: audit:unknown
WHAT: ST-3-uecoOwdbdIn4bc2WvXfe-cas-test
ACTION: SERVICE_TICKET_VALIDATED
APPLICATION: CAS
WHEN: Wed Jun 03 08:54:10 CEST 2015
CLIENT IP ADDRESS: 127.0.0.1
SERVER IP ADDRESS: 127.0.0.1
=============================================================
08:54:10,810 DEBUG [org.springframework.validation.DataBinder] (http-/0.0.0.0:8080-7) DataBinder requires binding of required fields [renew]
08:54:10,811 DEBUG [org.springframework.web.servlet.DispatcherServlet] (http-/0.0.0.0:8080-7) Rendering view [org.springframework.web.servlet.view.InternalResourceView: name 'cas2ServiceSuccessView'; URL [/WEB-INF/view/jsp/cas2ServiceSuccessView.jsp]] in DispatcherServlet with name 'cas'
08:54:10,811 DEBUG [org.springframework.web.servlet.view.InternalResourceView] (http-/0.0.0.0:8080-7) Added model object 'assertion' of type [org.jasig.cas.validation.ImmutableAssertion] to request in view with name 'cas2ServiceSuccessView'
08:54:10,811 DEBUG [org.springframework.web.servlet.view.InternalResourceView] (http-/0.0.0.0:8080-7) Removed model object 'pgtIou' from request in view with name 'cas2ServiceSuccessView'
08:54:10,811 DEBUG [org.springframework.web.servlet.view.InternalResourceView] (http-/0.0.0.0:8080-7) Forwarding to resource [/WEB-INF/view/jsp/cas2ServiceSuccessView.jsp] in InternalResourceView 'cas2ServiceSuccessView'
08:54:10,812 DEBUG [org.springframework.web.servlet.DispatcherServlet] (http-/0.0.0.0:8080-7) Successfully completed request
08:54:10,814 DEBUG [org.springframework.web.servlet.DispatcherServlet] (http-/0.0.0.0:8080-7) DispatcherServlet with name 'cas' processing GET request for [/cas/login]
08:54:10,814 DEBUG [org.springframework.webflow.mvc.servlet.FlowHandlerMapping] (http-/0.0.0.0:8080-7) Mapping request with URI '/cas/login' to flow with id 'login'
In SpringSecurity 4.x, CasAuthenticationFilter's defaultFilterProcessesUrl path is changed.
So Change '/j_spring_cas_security_check' to '/login/cas' in Configuration.
... and of course, the cause was rather silly: somehow (I have to look at our merge/git history), the viewResolver bean defined in cas-servlet.xml did not have a basenames property set.