I'm trying to debug an issue in kerberos configuration. I generated a service ticket using the kgetcred utility. I'd like to access the value of the service ticket so that I can put it into the Authorization header of a request to the protected resource.
I ran the following:
kinit myUser
kgetcred HTTP/myProtectedResource#MY.DOMAIN.COM
I can see the ticket exists by running
$klist
Credentials cache: FILE:/tmp/krb5cc_1000
Principal: myUser#MY.DOMAIN.COM
Issued Expires Principal
Jan 30 15:37:39 2017 Jan 31 01:37:39 2017 krbtgt/MY.DOMAIN.COM#MY.DOMAIN.COM
Jan 30 16:02:39 2017 Jan 31 01:37:39 2017 HTTP/myProtectedResource#MY.DOMAIN.COM
I had a look inside the /tmp/krb5cc_1000 file, but this seems encrypted of encoded somehow.
How can I get the value of this ticket to put in the Authorization header when making an HTTP request to the protected resource?
Related
What is the proper way to logout?
These are the keycloak client settings:
Realm: REALM
Client ID: pkce-client
Client Protocol: openid-connect
Access Type: public
Standard Flow Enabled: ON
Valid Redirect URIs: http://localhost:4200/
Backchannel Logou: ON
OpenID Connect Compatibility Modes
Use Refresh Tokens: ON
Advanced Settings:
Proof Key for Code Exchange Code Challenge Method: S256
Is there a good documentation?
My idea was to delete the token on the client side, but then the session is still active in keycloak.
The solution was to call the following URL:
http://localhost:8180/auth/realms/REALM/protocol/openid-connect/logout?id_token_hint=InR5cCIgOiAiSldUIiwia2lkIiA6ICIxUVJwMXAtbmk1WmcyZmlyRHFoRS1iS1hwemZDaWFocGs4Zi1XRkQtRDZ3In0.eyJleHAiOjE2NDE3NjUyNjYsImlhdCI6MTY0MTc2.......
OIDC standard (implemented by Keycloak) supports RP initiated logout. So make browser redirect (not a XMLHttpRequest request only) to end_session_endpoint with proper logout parameters.
BTW: end_session_endpoint is not the same as revocation_endpoint; logout != revocation.
But this is OIDC logout only (logout from the Keycloak). You may have still own app session (it depends on the app implementation), so app needs to destroy app session ("delete refresh token on the client side", ...) to have logout from the app.
You can create a logout service backend that you make available on /logout endpoints of all your services.
When the service is called, it first obtains the ID token for the client used to connect:
curl -k https://<keycloak-host>/auth/realms/<realm>/protocol/openid-connect/token \
-d "grant_type=client_credentials" \
-d "client_id=<client-id>" \
-d "client_secret=<secret>" \
-d "scope=openid"
See this answer.
Then it constructs a redirect URL in a format like this based on host of user:
https://<host>?cache-buster=1445660571
With an optional cache buster.
Create a redirect URL to the authorization server in this format:
https:///auth/realms//protocol/openid-connect/logout?id_token_hint=&post_logout_redirect_uri=<url encoded redirect URL>
Then create a response with status code 303 (See Other) with as Location the URL constructed above, and as headers you set the "kc-access", "kc-state", "OAuth_Token_Request_State" and "request_uri" cookies to expired. Clojure example:
(defn- expired-cookie [host cookie-name]
(str cookie-name "=; "
"domain=." host "; "
"path=/; "
"expires=Thu, 01 Jan 1970 00:00:00 GMT; "
"HttpOnly"))
Example response:
status: 303
headers:
{"Location" "https://<keycloak host>/auth/realms/<realm>/protocol/openid-connect/logout
?id_token_hint=<id token you obtained>
&post_logout_redirect_uri=<url encoded redirect URL>"
"Set-Cookie"
["kc-access=; domain=.https://<domain>; path=/;
expires=Thu, 01 Jan 1970 00:00:00 GMT; HttpOnly"
"kc-state=; domain=.https://<domain>; path=/;
expires=Thu, 01 Jan 1970 00:00:00 GMT; HttpOnly"
"OAuth_Token_Request_State=; domain=.https://<domain>; path=/;
expires=Thu, 01 Jan 1970 00:00:00 GMT; HttpOnly"
"request_uri=; domain=.https://<domain>; path=/;
expires=Thu, 01 Jan 1970 00:00:00 GMT; HttpOnly"]}
This returned response will log the user out and redirect to the constructed redirect URL (for example, where the user came from).
This /logout endpoint can be made available as a route on all services that use Keycloak.
The solution was to call the following URL:
http://localhost:8180/auth/realms/REALM/protocol/openid-connect/logout?id_token_hint=InR5cCIgOiAiSldUIiwia2lkIiA6ICIxUVJwMXAtbmk1WmcyZmlyRHFoRS1iS1hwemZDaWFocGs4Zi1XRkQtRDZ3In0.eyJleHAiOjE2NDE3NjUyNjYsImlhdCI6MTY0MTc2.......
I'm curious if anyone else has seen the following behavior from the Office 365 REST API beta when attempting to retrieve Outlook tasks for users other than one's self?
I've confirmed that I've granted my application the necessary permissions for it to retrieve tasks for all users:
https://outlook.office.com/api/beta/me/tasks
-> I get a result
https://outlook.office.com/api/beta/users/abc#xyz.com/tasks
-> I get a 403 forbidden error
If developer is reading this, could this be an issue w/the beta API which will be corrected in the near future? Or, is there something else which could be going sideways?
Aside from "tasks", I can retrieve contacts, mail, etc. from other users just fine.
Here is the response I get whenever I attempt to query another user's tasks:
HTTP/1.1 403 Forbidden
Transfer-Encoding: chunked
request-id: 5c375fd9-d5ed-4fd3-8e1a-ab3dc61feaf3
X-CalculatedFETarget: BN3PR03CU002.internal.outlook.com
X-BackEndHttpStatus: 403, 403
X-FEProxyInfo: BN3PR0301CA0017.NAMPRD03.PROD.OUTLOOK.COM
X-CalculatedBETarget: BN3PR0501MB1298.namprd05.prod.outlook.com
x-ms-diagnostics: 2000008;reason="The token contains not enough scope to make this delegate access call.";error_category="invalid_grant"
OData-Version: 4.0
X-DiagInfo: BN3PR0501MB1298
X-BEServer: BN3PR0501MB1298
X-FEServer: BN3PR0301CA0017, CO1PR06CA031
X-MSEdge-Ref: Ref A: 5CE3BDDBE9BB483ABA0F13CE2EC07F80 Ref B: 52E8D7443714773298F8956513923AFC Ref C: Thu Jun 30 12:59:31 2016 PST
Cache-Control: private
Date: Thu, 30 Jun 2016 19:59:31 GMT
Set-Cookie: exchangecookie=e4b8e5f48581449893f48eba48413e88; expires=Fri, 30-Jun-2017 19:59:31 GMT; path=/; HttpOnly
Server: Microsoft-IIS/8.5
WWW-Authenticate: Bearer client_id="00000002-0000-0ff1-ce00-000000000000", trusted_issuers="00000001-0000-0000-c000-000000000000#*", token_types="app_asserted_user_v1 service_asserted_app_v1", error="invalid_token"
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
{
"error": {
"code": "ErrorAccessDenied",
"message": "Access is denied. Check credentials and try again."
}
}
It says that, "The token contains not enough scope to make this delegate access call."
However: I have confirmed that 9/9 "Application Permissions" as well as 26/26 "Delegated Permissions" have been granted to the app for the "Office 365 Exchange Online" service. Additionally, the account I'm using is also a Global Administrator for our tenant.
Thanks for any help!
At present, the Task API requests are always performed on behalf of the signed-in user(refer to target user).
And there is no such scope that for reading task from all users, you can refer to the permissions from figure below:
You may submit the feedback from here if you require that the Task API to support for other users.
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)
I was trying to use it for Single sing on. I was able to successfully secure my web services/pages and want to extend it to my REST APIs (services) as well. I am using CAS 4.0.0.
I followed this link http://jasig.github.io/cas/4.0.0/protocol/REST-Protocol.html and change the web.xml as suggested and added the following jar to my CAS deployment WEB-INF/lib folder:
cas-server-integration-restlet-4.0.0.jar
org.restlet.jar
org.restlet.ext.spring.jar
org.restlet.ext.servlet.jar
The Call to the "v1/tickets" is reaching the restlet-frame work but I am getting a 404 error to my rest client
Status Code: 404 Not Found
Accept-Ranges: bytes
Content-Length: 439
Content-Type: text/html;charset=UTF-8
Date: Thu, 06 Nov 2014 13:12:46 GMT
Server: Restlet-Framework/2.2.2
Can you Please help me identify the issue with the set-up or point me to a detailed documentation.
Disclaimer: I'm the Chairman of CAS and founder of CAS in the cloud (https://www.casinthecloud.com).
The endpoint is in lower-case: can you try: /v1/tickets?