OpenShift3 API Refresh Token - api

I'm looking into OpenShift3 API to refresh a authenticated token.
I've authenticated and have a existing token but would need to refresh it every 30mins.
From the documentation - https://docs.openshift.com/enterprise/3.0/rest_api/openshift_v1.html#create-a-oauthaccesstoken
It requires a v1.OAuthAccessToken object but everything is optional, calling it with a empty object returns with this error:
{ kind: 'Status',
apiVersion: 'v1',
metadata: {},
status: 'Failure',
message: 'User "admin01" cannot create oauthaccesstokens at the cluster scope',
reason: 'Forbidden',
details: { kind: 'oauthaccesstokens' },
code: 403 }
Anyone any help? Thanks in advance.

Related

Cognito Custom Auth trigger not getting Session from Cognito

I tried to call the InitiateAuth API from AWS CLI. I have set up Define auth, create auth and verify auth lambda triggers correctly. The problem is that, when I ran the below command, it's showing error:
aws cognito-idp initiate-auth --client-id <my_client_id> --auth-flow CUSTOM_AUTH --auth-parameters USERNAME=uname,ChallengeName="SRP_A",SRP_A="<srp_value>"
Error: An error occurred (UserLambdaValidationException) when calling the InitiateAuth operation: DefineAuthChallenge failed with error Cannot read property 'challengeName' of undefined.
I checked the Define Auth lambda code, and also the Cloud Watch logs of Lambda execution. The error occurred because the input from Cognito contains an empty session key in the event json (which usually sent from Cognito to Lambda). As the property challengeName resides inside the session key (as shown in official documentation).
Here is the JSON event sent to Lambda from Cognito when I ran that command (I got this JSON from CloudWatch Lambda logs, I printed the event which is being sent from Cognito):
{
version: '1',
region: 'us-east-1',
userPoolId: 'us-east-1_******',
userName: 'uname',
callerContext: {
awsSdkVersion: 'aws-sdk-unknown-unknown',
clientId: '<my_client_id>'
},
triggerSource: 'DefineAuthChallenge_Authentication',
request: {
userAttributes: {
sub: 'xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx',
'cognito:email_alias': '<email>',
'cognito:user_status': 'CONFIRMED',
email_verified: 'true',
name: 'Custom Test',
email: '<email>'
},
session: [], -----> !! Empty
userNotFound: false
},
response: { challengeName: null, issueTokens: null, failAuthentication: null }
}
What is the reason? Is it because I am sending the request from CLI so Cognito not able to create a session or something? I'm not sure. Any help will be appreciated.
Session holds previous auth challenge results (either from built-in challenges or you custom challenges). It will be empty for the first invocation of the define auth challenge lambda. As the name suggests you have to define the auth challenge in the handler response.

Authenticate AppSync queries console with Cognito User Pools

I am trying to authenticate Queries playground in AWS AppSync console. I have created User Pool and linked it to the AppSync API, I have also created an App Client in Cognito User Pool (deployed using CloudFormation). It appears under Select the authorization provider to use for running queries on this page: in the console.
When I run test query I get:
{
"errors": [
{
"errorType": "UnauthorizedException",
"message": "Unable to parse JWT token."
}
]
}
This is what I would expect. There is an option to Login with User Pools. The issue is I can't select any Client ID and when I choose to insert Client ID manually, anything I enter I get Invalid UserPoolId format. I am trying to copy Pool ID from User Pool General settings (format eu-west-2_xxxxxxxxx) but no joy. Btw, I am not using Amplify and I have not configured any Identity Pools.
EDIT:
Here is the CloudFormation GraphQLApi definition:
MyApi:
Type: AWS::AppSync::GraphQLApi
Properties:
Name: !Sub "${AWS::StackName}-api"
AuthenticationType: AMAZON_COGNITO_USER_POOLS
UserPoolConfig:
UserPoolId: !Ref UserPoolClient
AwsRegion: !Sub ${AWS::Region}
DefaultAction: ALLOW
To set up the stack using CloudFormation I have followed these 2 examples:
https://adrianhall.github.io/cloud/2018/04/17/deploy-an-aws-appsync-graphql-api-with-cloudformation/
https://gist.github.com/adrianhall/f330a10451f05a529680f32978dddb64
Turns out they both (same author) have an issue in them in the section where ApiGraphQL is defined. This:
MyApi:
Type: AWS::AppSync::GraphQLApi
Properties:
Name: !Sub "${AWS::StackName}-api"
AuthenticationType: AMAZON_COGNITO_USER_POOLS
UserPoolConfig:
UserPoolId: !Ref UserPoolClient
AwsRegion: !Sub ${AWS::Region}
DefaultAction: ALLOW
Should be:
MyApi:
Type: AWS::AppSync::GraphQLApi
Properties:
Name: !Sub "${AWS::StackName}-api"
AuthenticationType: AMAZON_COGNITO_USER_POOLS
UserPoolConfig:
UserPoolId: !Ref UserPool
AwsRegion: !Sub ${AWS::Region}
DefaultAction: ALLOW
Thank you #Myz for pointing me back to review the whole CF yaml file

Authorization Policy Issue when followed Istio 1.5 Security

I was trying to set up Authorization Policy by following Istio 1.5 Security,
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: require-jwt
namespace: foo
spec:
selector:
matchLabels:
app: httpbin
action: ALLOW
rules:
- from:
- source:
requestPrincipals: ["testing#secure.istio.io/testing#secure.istio.io"]
But when I apply this policy for my service then I get ‘RBAC: access denied’
Please find the envoy proxy logs below,
[Envoy (Epoch 0)] [2020-03-27 14:40:31.225][24][debug][rbac] [external/envoy/source/extensions/filters/http/rbac/rbac_filter.cc:68] checking request: remoteAddress: 10.1.0.65:57780, localAddress: 10.1.0.64:9080, ssl: uriSanPeerCertificate: spiffe://cluster.local/ns/istio-system/sa/istio-ingressgateway-service-account, subjectPeerCertificate: ,
headers: ‘:authority’, ‘localhost’
‘:path’, ‘/productpage’
‘:method’, ‘GET’
‘content-type’, ‘application/json’
**‘authorization’, ‘Bearer eyJhbGciOiJSUzI1NiIsImtpZCI6IkRIRmJwb0lVcXJZOHQyenBBMnFYZkNtcjVWTzVaRXI0UnpIVV8tZW52dlEiLCJ0eXAiOiJKV1QifQ.eyJleHAiOjM1MzczOTExMDQsImdyb3VwcyI6WyJncm91cDEiLCJncm91cDIiXSwiaWF0IjoxNTM3MzkxMTA0LCJpc3MiOiJ0ZXN0aW5nQHNlY3VyZS5pc3Rpby5pbyIsInNjb3BlIjpbInNjb3BlMSIsInNjb3BlMiJdLCJzdWIiOiJ0ZXN0aW5nQHNlY3VyZS5pc3Rpby5pbyJ9.EdJnEZSH6X8hcyEii7c8H5lnhgjB5dwo07M5oheC8Xz8mOllyg–AHCFWHybM48reunF–oGaG6IXVngCEpVF0_P5DwsUoBgpPmK1JOaKN6_pe9sh0ZwTtdgK_RP01PuI7kUdbOTlkuUi2AO-qUyOm7Art2POzo36DLQlUXv8Ad7NBOqfQaKjE9ndaPWT7aexUsBHxmgiGbz1SyLH879f7uHYPbPKlpHU6P9S-DaKnGLaEchnoKnov7ajhrEhGXAQRukhDPKUHO9L30oPIr5IJllEQfHYtt6IZvlNUGeLUcif3wpry1R5tBXRicx2sXMQ7LyuDremDbcNy_iE76Upg’**
‘user-agent’, ‘PostmanRuntime/7.22.0’
‘accept’, ‘/’
‘cache-control’, ‘no-cache’
‘postman-token’, ‘f06a794e-1bd7-4c03-ad78-1638a309b71a’
‘accept-encoding’, ‘gzip, deflate, br’
‘content-length’, ‘4868’
‘x-forwarded-for’, ‘192.168.65.3’
‘x-forwarded-proto’, ‘http’
‘x-request-id’, ‘012804b1-67ca-942d-9636-40478e932e75’
‘x-b3-traceid’, ‘f8f9e4f94847aec5ce7dec347a5bfa5d’
‘x-b3-spanid’, ‘ce7dec347a5bfa5d’
‘x-b3-sampled’, ‘1’
‘x-envoy-internal’, ‘true’
‘x-forwarded-client-cert’, ‘By=spiffe://cluster.local/ns/default/sa/bookinfo-productpage;Hash=5e82efecebbaf212aae6359cec7cbc0b6aa281ddeaf3e7adb280c503a5c04a5f;Subject="";URI=spiffe://cluster.local/ns/istio-system/sa/istio-ingressgateway-service-account’
, dynamicMetadata: filter_metadata {
key: “istio_authn”
value {
fields {
key: “request.auth.principal”
value {
string_value: “cluster.local/ns/istio-system/sa/istio-ingressgateway-service-account”
}
}
fields {
key: “source.namespace”
value {
string_value: “istio-system”
}
}
fields {
key: “source.principal”
value {
string_value: “cluster.local/ns/istio-system/sa/istio-ingressgateway-service-account”
}
}
fields {
key: “source.user”
value {
string_value: “cluster.local/ns/istio-system/sa/istio-ingressgateway-service-account”
}
}
}
}
**[Envoy (Epoch 0)] [2020-03-27 14:40:31.225][24][debug][rbac] [external/envoy/source/extensions/filters/http/rbac/rbac_filter.cc:111] enforced denied**
[2020-03-27T14:40:31.224Z] “GET /productpage HTTP/1.1” 403 - “-” “-” 0 19 1 - “192.168.65.3” “PostmanRuntime/7.22.0” “012804b1-67ca-942d-9636-40478e932e75” “localhost” “-” - - 10.1.0.64:9080 192.168.65.3:0 outbound_.9080_._.productpage.default.svc.cluster.local -
Please help me to solve this issue. Thanks in advance
Try to update istio to v 1.5.1.
According to istio documentation there was a bug fixed that affected authentication policy security.istio.io/v1beta1 that You are using:
Fixed OpenID discovery does not work with beta request authentication policy (Issue 21954)
To perform istio upgrade please review istio upgrade documentation page.
Hope it helps.

How to avoid that AWS Amplify OAuth tries to parse every oauth process

I'm working with a react-native application where i have implement the Authentication flow using AWS Amplify and Federated signin. This is the amplify configuration:
Auth: {
identityPoolId: 'XXX',
region: 'XXX',
mandatorySignIn: false,
userPoolId: 'XXX',
userPoolWebClientId: 'XXX',
oauth: {
domain: env.AWS_OAUTH_DOMAIN,
scope: ['email', 'profile', 'openid','aws.cognito.signin.user.admin', 'given_name', 'family_name', 'user_gender', 'user_birthday', 'user_location'],
redirectSignIn: myapp://signin,
redirectSignOut: myapp://logout,
responseType: 'code',
},
},
Everything works fine. Until now.
Now i have to add another OAuth authentication for other purposes (connecting Strava to my application). Everything works fine, until the Strava authorization dialog redirect to my app at the url: runcard://profilo/servizi?code=XXX&scope=activity%3Aread%2Cread (this callback url is different from the one i've set for amplify configuration). Once redirected, amplify is there, ready to raise an exception by Amplify OAuth:
WARN Possible Unhandled Promise Rejection (id: 0):
TypeError: undefined is not an object (evaluating '_a.accessToken')
I believe that since the callback url has a code parameter, Amplify is trying to do the job himself. Without success.
Does anyone faced the same issue?
I found the cause of the issue!
Amplify is specifically looking for a param in any deeplinked URL called code.
I too was using code for a purpose other than the oauth callback (sign up confirmation code).
Changing the param to anything else (e.g. confirmationCode) prevents the accessToken error.
At the end, I've used this workaround: I removed the Amplify listener and I added a new listener that will parse only Amplify OAuth URLs.
Amplify.configure({ ... });
Analytics.getInstance();
// Workaround: this is to avoid that Amplify OAuth try to parse EVERY url as a OAuth callback url
// https://stackoverflow.com/questions/59883011/how-to-avoid-that-aws-amplify-oauth-tries-to-parse-every-oauth-process
Linking.removeAllListeners('url');
Linking.addEventListener('url', (url) => {
if (url.url.indexOf(AWS_OAUTH_REDIRECT_SIGNIN !== -1 || url.url.indexOf(AWS_OAUTH_REDIRECT_SIGNOUT) !== -1) {
Amplify.Auth._handleAuthResponse(url.url);
}
});
AWS_OAUTH_REDIRECT_SIGNIN and AWS_OAUTH_REDIRECT_SIGNOUT are the same specified in Amplify configuration:
AWS: {
Auth: {
oauth: {
redirectSignIn: AWS_OAUTH_REDIRECT_SIGNIN,
redirectSignOut: AWS_OAUTH_REDIRECT_SIGNOUT,
responseType: 'code'
}
}
}

Serverless function with authorizer arn provided returns 401

I am using serverless.
When I setup one of my functions as the following, which includes authorizer, on the client, I receive 401.
However when I remove it, there are no problems.
provider:
name: aws
runtime: nodejs8.10
region: eu-west-1
environment:
USER_POOL_ARN: "arn:aws:cognito-idp:eu-west-1:974280.....:userpool/eu-west-1........"
functions:
create:
handler: handlers/create.main
events:
- http:
path: create
method: post
cors: true
authorizer:
type: COGNITO_USER_POOLS
name: serviceBAuthFunc
arn: ${self:provider.environment.USER_POOL_ARN}
On the client, I expect a logged in user of the same user pool could get expected response. However it returns 401.
Any help is appreciated. Thanks.
After desperate hours spent, I have come up with the solution.
For anyone who comes across the same issue, here is a solution that worked for me.
Add integration: lambda after cors: true (though the order doesn't matter).
Below is just demonstrating that.
functions:
create:
handler: handlers/create.main
events:
- http:
path: create
method: post
cors: true
integration: lambda // this solves the problem
authorizer:
type: COGNITO_USER_POOLS
name: serviceBAuthFunc
arn: ${self:provider.environment.USER_POOL_ARN}
Send Authorization header with the value of Auth.currentSession().idToken.jwtToken while making the request.
Below is an example for sending headers using API of #aws-amplify/api and Auth of #aws-amplify/auth.
const currentSession = await Auth.currentSession()
await API.post(
'your-endpoint-name',
"/your-endpoint-path/..",
{
headers: {
'Authorization': currentSession.idToken.jwtToken
}
}
)