CyberSource Payment with Flex API V2 Token UnAuthorised issue? - jwt

When I am using cyberSource Payment with Flex V2 Token always i am getting 401 Unauthorized error.
Headear and Request API:
Request{method=POST, url=https://apitest.cybersource.com/pts/v2/payments, headers=[v-c-merchant-id:testloginshan, Accept:application/jwt, Date:Wed, 7 Dec 2022 05:44:15 GMT, Host:apitest.cybersource.com, User-Agent:Mozilla/5.0, Signature:keyid="8f5aa7fe-4746-4cf2-beae-62f74cd1e140", algorithm="HmacSHA256", headers="host date (request-target) digest v-c-merchant-id", signature="01Er6UfHx/rOC5dEsEPCFcGcDzGU0ujvEM9Lzp85RJY=", Digest:SHA-256=xLxNBV4ETfGKjD1+b1m+uPdVjA5rc3uieprBWXABvKE=], tags={class retrofit2.Invocation=com.cybersource.flex.sessions.api.FlexSessionService.sendPayment() [okhttp3.RequestBody$Companion$toRequestBody$2#1bbd119, {v-c-merchant-id=testloginshan, Accept=application/jwt, Content-Type=application/json;charset=utf-8, Date=Wed, 7 Dec 2022 05:44:15 GMT, Host=apitest.cybersource.com, User-Agent=Mozilla/5.0, Signature=keyid="8f5aa7fe-4746-4cf2-beae-62f74cd1e140", algorithm="HmacSHA256", headers="host date (request-target) digest v-c-merchant-id", signature="01Er6UfHx/rOC5dEsEPCFcGcDzGU0ujvEM9Lzp85RJY=", Digest=SHA-256=xLxNBV4ETfGKjD1+b1m+uPdVjA5rc3uieprBWXABvKE=}]}}

Related

What is the best approach to logout from keycloak after authentication via pkce?

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.......

how can I access the value of a service ticket from kerberos cache?

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?

Any modification to API Gateway's Integration Response Mapping Templates causes 500 error

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

Microsoft Calendar REST API - Access to OData is disabled

I'm trying to access Microsoft's Outlook.com Calendar REST API. I got OAUTH2 authentication set up correctly and have a valid access token and refresh token available.
However, if I try to access the calendar list # https://outlook.office.com with my access token:
GET /api/v1.0/me/calendars HTTP/1.1
Accept: application/json; odata.metadata=none
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciO[...]
the service returns with an 403 Forbidden
HTTP/1.1 403 Forbidden
Cache-Control: private
Transfer-Encoding: chunked
Content-Type: application/json;odata.metadata=minimal;odata.streaming=true;IEEE754Compatible=false;charset=utf-8
Server: Microsoft-IIS/8.5
Set-Cookie: ClientId=OD6KHQBTKOKMLXUI8OJEG; expires=Wed, 21-Sep-2016 18:37:21 GMT; path=/; secure; HttpOnly
Set-Cookie: exchangecookie=8e4f582170cb445780c7148e9494b293; expires=Thu, 22-Sep-2016 18:37:23 GMT; path=/; HttpOnly
Set-Cookie: ClientId=OD6KHQBTKOKMLXUI8OJEG; expires=Wed, 21-Sep-2016 18:37:21 GMT; path=/; secure; HttpOnly
request-id: 7113f37d-69e0-4f8c-a264-9f3599d47899
X-CalculatedBETarget: CY1PR08MB1801.namprd08.prod.outlook.com
X-BackEndHttpStatus: 403
OData-Version: 4.0
X-AspNet-Version: 4.0.30319
X-DiagInfo: CY1PR08MB1801
X-BEServer: CY1PR08MB1801
X-Powered-By: ASP.NET
X-FEServer: AM3PR04CA0074
X-MSEdge-Ref: Ref A: D69A31E4FAA44258B0B8C351A71D2F9E Ref B: 0D3CA60C0976F50C452293F8CF403D8C Ref C: Tue Sep 22 11:37:23 2015 PST
Date: Tue, 22 Sep 2015 18:37:22 GMT
{"error":{"code":"ErrorAccessDenied","message":"Access to OData is disabled."}}
I played around with Outlook's OAuth Sandbox, where the same request returns a 200 OK with the correct data in the body. Strangely enough, they spot a nice little Show me the cURL! button in the sandbox, but this exact curl command will fail again with a 403 error in my terminal.
What am I missing?
I talked to a Microsoft techie. My problem was, that the REST API is not public (yet) and Microsoft has not yet enabled the API for standard Outlook.com accounts.
I requested an Outlook developer preview account with the REST API enabled by writing an email to outlookdev#microsoft.com
It took some time until I got a response from Microsoft, but using the developer account everything works now as expected.

Invoke API error - AWS API gateway

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)