paradigm
Hello Everyone
I am trying to integrate SSO on Redmine using keycloak with google as identity provider, i almost got there till i get this error after login account with google and keycloak return redmine following error.
Log redmine:
Completed 200 OK in 53ms (Views: 39.3ms | ActiveRecord: 9.6ms)
Started GET "/auth/saml" for 42.113.145.55 at 2022-08-29 15:09:34 +0700
Started POST "/auth/saml/callback" for 42.113.145.55 at 2022-08-29 15:09:34 +0700
Started GET "/auth/failure?message=invalid_ticket&origin=https%3A%2F%2Fdomain redmine%2Flogin&strategy=saml" for 42.113.145.55 at 2022-08-29 15:09:34 +0700
Processing by AccountController#login_with_saml_failure as HTML
Parameters: {"message"=>"invalid_ticket", "origin"=>"https://domain redmine/login", "strategy"=>"saml"}
Current user: anonymous
Redirected to http://domain redmine/login
Completed 302 Found in 7ms (ActiveRecord: 1.7ms)
Started GET "/login" for 42.113.145.55 at 2022-08-29 15:09:35 +0700
Processing by AccountController#login as HTML
enter image description here
i'm guessing that the cause of the problem lies in the mappers identity provider, client on Keycloak , i have no experience with this , can someone help me to see if my mappers configuration is correctenter image description here
enter image description here
Related
I'm using OpenAM 13 and Web Policy Agent 4.0 for apache.
It seems that Web Policy Agent could not recognize an iPlanetDirectoryPro cookie, which is a token set by OpenAM after authentication, is expired or is actually an invalid one.
Looks like Web Policy Agent would take the token and confirm it with OpenAM, then be told the validation failed, like these lines of log below, and give the user a 403 forbidden page.
2017-01-24 11:29:55.475 +0800 WARNING [0x7f180e887700:17669] am_get_session_policy_cache_entry(): failed to locate data for a key (AQIC5wM2LY4SfcxFG6Bl98dRT7AluZ7682rulJGU8-CCSN4.*AAJTSQACMDEAAlNLABQtMTQ2NTcwMTgyOTEwMjQ5MTg4OQACUzEAAA..*)
2017-01-24 11:29:55.484 +0800 WARNING [0x7f180e887700:17669] validate_policy(): retry 0 (remote session/policy call failure: error)
2017-01-24 11:29:57.490 +0800 WARNING [0x7f180e887700:17669] validate_policy(): retry 1 (remote session/policy call failure: error)
2017-01-24 11:29:59.497 +0800 WARNING [0x7f180e887700:17669] validate_policy(): retry 2 (remote session/policy call failure: error)
2017-01-24 11:30:01.504 +0800 WARNING [0x7f180e887700:17669] validate_policy(): retry 3 (remote session/policy call failure: error)
2017-01-24 11:30:03.504 +0800 ERROR [0x7f180e887700:17669] validate_policy(): remote session/policy call to validate 'http://agent.job.com.tw:80/notification/push' failed (max 3 retries exhausted)
The expected behavior under that situation is redirect the user to auth, I think so, if the user is valid and has no permission to access that page, agent would be instructed to block the user out of it, like this one below.
2017-01-24 11:43:59.009 +0800 WARNING [0x7f17f9ff3700:17669] am_get_session_policy_cache_entry(): failed to locate data for a key (AQIC5wM2LY4Sfcz6gBnS77c_KhZogqv6gYGQdjU1WpRaQxE.*AAJTSQACMDEAAlNLABMzMTYxMjIwNDAzNjc4NDA4MDQxAAJTMQAA*)
2017-01-24 11:43:59.050 +0800 WARNING [0x7f17f9ff3700:17669] validate_policy(): decision: deny, reason: no action decisions found
2017-01-24 11:43:59.213 +0800 WARNING [0x7f180d000700:17669] validate_policy(): validate policy did not find a match for 'http://agent.job.com.tw:80/favicon.ico' in the cached entries, retrying with the new request to the policy service
2017-01-24 11:43:59.227 +0800 WARNING [0x7f180d000700:17669] validate_policy(): decision: deny, reason: no action decisions found
However, if I navigate to the OpenAM server page by myself, regardless before or after accessing the resource page and get a 403 page back, OpenAM would ask me to auth! On other words, to login, and the iPlanetDirectoryPro cookie disappeared, I guess it was cleared by OpenAM, so this means that OpenAM is able to distinguish an expired session, or at least, it knows how to take care of an iPlanetDirectoryPro cookie which is no longer effective.
If I choose not to login immediately, and head back to the resource page, it starts to redirect to OpenAM for authentication which is good. When getting 403 page, remove the iPlanetDirectoryPro cookie manually will do the same trick.
Well this is really annoying, and could be critical for general users, they won't be aware to do those workaround mentioned above.
I wish there's somebody kind could help me with this problem, many thanks.
I believe you are running into this bug: AMAGENTS-279
I'm in Amazon's API Gateway, and any change to the Mapping Templates section of the Integration Response breaks the Resource/Method (causes the Test to return an error) and cannot be fixed (you must delete the Resource/Method and create a new one).
I create a new Resource, then create a new Method (POST) under that.
I map this to a simple Lambda function (it doesn't require any parameters and only returns/logs 'hi').
I test this, and it succeeds.
I go into Integration Response, and I change the Mapping Templates ... I change application/json to application/xml and I change 'Output passthrough' to 'Mapping template'.
I enter this as the template:
#set($inputRoot = $input.path('$'))
<?xml version="1.0" encoding="UTF-8"?>
<Response>
<Message>
<Body>
$inputRoot
</Body>
</Message>
</Response>
I save that by clicking the checkbox and by clicking the Save button.
I go back to test it
This is the result:
{
"message": "Internal server error"
}
This is the content of the Logs output (I replaced potentially sensitive information with [explanation here] since I'm not sure what's sensitive or not):
Execution log for request test-request
Sun Dec 06 17:33:50 UTC 2015 : Starting execution for request: test-invoke-request
Sun Dec 06 17:33:50 UTC 2015 : API Key: test-invoke-api-key
Sun Dec 06 17:33:50 UTC 2015 : Method request path: {}
Sun Dec 06 17:33:50 UTC 2015 : Method request query string: {}
Sun Dec 06 17:33:50 UTC 2015 : Method request headers: {}
Sun Dec 06 17:33:50 UTC 2015 : Method request body before transformations: null
Sun Dec 06 17:33:50 UTC 2015 : Endpoint request URI: [lambda uri here]
Sun Dec 06 17:33:50 UTC 2015 : Endpoint request headers: {Authorization=[lots of * here], X-Amz-Date=20151206T173350Z, X-Amz-Source-Arn=[arn here], Accept=application/json, User-Agent=AmazonAPIGateway_[string here], Host=lambda.us-east-1.amazonaws.com}
Sun Dec 06 17:33:50 UTC 2015 : Endpoint request body after transformations:
Sun Dec 06 17:33:50 UTC 2015 : Endpoint response body before transformations: "hi"
Sun Dec 06 17:33:50 UTC 2015 : Endpoint response headers: {x-amzn-Remapped-Content-Length=0, x-amzn-RequestId=[data here], Connection=keep-alive, Content-Length=12, Date=Sun, 06 Dec 2015 17:33:50 GMT, Content-Type=application/json}
Sun Dec 06 17:33:50 UTC 2015 : Execution failed due to configuration error: No match for output mapping and no default output mapping configured
Sun Dec 06 17:33:50 UTC 2015 : Method completed with status: 500
I also tried going into Method Response, and changing the Content Type for Response Models for 200 from application/json to application/xml ... That produced the same error.
I also tried, at this point, to revert my changes ... Method Response back to application/json & Integration Response back to application/json and 'Output passthrough' ... That produced the same error - it's like this API Resource/Method is now permanently broken.
I also tested another new Resource, changing only the Content Type for Response Models for 200 in Method Response from 'application/json' to 'application/xml' ... This resulted in a successful test.
I also tried a more minor change to the Mapping Templates in Integration Response ... Rather than a full switch from 'Output passthrough' to 'Mapping Template', I just changed the content type from application/json to application/xml ... This resulted in the same error.
So it seems like the root cause is changing from Output Passthrough to Mapping Template ... Once that change is made, the test will fail & you will not be able to return it to a passing state - you must delete the Resource/Method entirely & start a new one.
Also, to be clear, there are no deploys throughout any of this process - I'm strictly working in the AWS console itself, using their 'Test' link in the web interface.
Anyone know what's going on here?
I'm also trying to get an answer in their Discussion Forum, but those threads usually aren't nearly as active as here...
Added Note
I do have a functional deploy running, which uses this mapping template. That deploy is from 18:35 12-05-2015, so it's possible that this is a new error/change in the Amazon API Gateway...
This must have been a temporary issue with API Gateway, because the issue is gone now.
There's one caveat:
NEVER click the big Save button on the Integration Response page. That seems to cause issues, at least as of today (2015-12-05).
I spoke with amazon's support staff and its a known issue. As long as you don't press the Save button you should be fine but once you do there is no going back.
Just press the checkbox thing when making changes to the template and refresh the page. That seems to work for me.
There was an issue with APIs when saving the default integration response mapping. The bug caused requests to your API methods that were saved incorrectly to return a 500 error, the CloudWatch logs should say "Execution failed due to configuration error: No match for output mapping and no default output mapping configured".
The issue is now resolved. If you are experiencing this, please re-deploy your API configuration.
For more information, please refer to this AWS forums entry: https://forums.aws.amazon.com/thread.jspa?threadID=221197&tstart=0
Regards,
Jurgen
The issue is now resolved. It's now safe to save the default integration response. If your deployed APIs are having issues, a redeploy should resolve the problem. Thanks for your patience.
Ryan
I'm trying to create an API using AWS API gateway
first I have created a resource as /sample
then created a method GET
provided Endpoint-URL and saved it.
In the Method Execution pane, select Method Request, added HTTP Request Headers as "Authorization" , added this to pass basic authentication details to back-end url since service is secured with basic authentication,
In the Method Execution pane, choose Integration Request, mapped HTTP Headers, Mapped from as "method.request.path.Authorization"
Choose Method Execution, and in the Client box, choose TEST, passed Header Authorization - Basic XXXXXX
After finished all the configuration successfully, tested the API , getting "message": "Internal server error" status code -500
For your reference my back-end service is running in the amazon-linux machine.
Checked logs:
Execution log for request test-request
Tue Sep 08 16:43:54 UTC 2015 : Starting execution for request: test-invoke-request
Tue Sep 08 16:43:54 UTC 2015 : API Key: test-invoke-api-key
Tue Sep 08 16:43:54 UTC 2015 : Method request path: {}
Tue Sep 08 16:43:54 UTC 2015 : Method request query string: {}
Tue Sep 08 16:43:54 UTC 2015 : Method request headers: {Authorization=************p1c2Vy}
Tue Sep 08 16:43:54 UTC 2015 : Method request body before transformations: null
Tue Sep 08 16:43:54 UTC 2015 : Execution failed due to configuration error: Invalid endpoint address
Could you please let me know how to resolve this issue?
try method.request.header.Authorization
Varun is right, your mapping expression is wrong.
The expression format for parameters in the request is "method.request.[source].[name]" where source is path/querystring/header and name is the name of the parameter as defined in the method request.
For the integration response, the format is the same exception you'd replace request with response and also note that only headers are available to map in the response.
If you want a quick fix just to start and get your API worked then follow these steps:
Steps
Login to AWS console
Go to "API Gateway" dashboard, select the resource(API) you need to invoke then select the method underneath (GET/POST/...)
On the method execution workflow, click on the "Method Response panel" and add status code 200 then you can add some headers for that.
Choose the "Response Body" and add "Application/json" with "Empty" model.
You should also click "Integration Request panel" and uncheck "Use Lambda Proxy integration" [as per attached image]
Last step
deploy your API into the stage(dev/test/prod)
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.
I just installed Jabber plugin for my Jenkins last week.
I have a XMPP server running for quite a long time, and there is no connection problem
From Jenkins log, I got some error "Jabber notifier plugin: There was an error sending notification to.
But this error does not happen all the time, it just pop up sometimes and disappeared after a while. And I cannot see anything wrong from Jenkins' log. and there is nothing generated after I created a system log for
hudson.plugins.jabber
as "FINEST" log level.
Nov 27, 2013 11:49:15 AM hudson.plugins.jabber.im.transport.JabberIMConnection
createConnection
INFO: Trying to connect to XMPP on <our_server>:5222/<our_server> with SASL
Nov 27, 2013 11:49:15 AM hudson.plugins.jabber.im.transport.JabberIMConnection
setupSubscriptionMode
INFO: Accepting all subscription requests
Nov 27, 2013 11:49:15 AM hudson.plugins.jabber.im.transport.JabberIMConnection connect
INFO: Connected to XMPP on <our_server>/<our_server> using TLS
Anyone knows if this is some stability issue with this plugin? Is there any way for me to do debug to see what exactly happened when this error pop up?
Thanks!