I am new to Keycloak. I have tried to get the user information using below code:
keycloakAuth.loadUserProfile().success(function(profile) {
debugger
console.log(profile);
}).error(function(res) {
debugger
console.log('Failed to load profile');
});
installation json is :
{
"realm": "CheckRealm",
"realm-public-key": "MIIBIjASDFJJK677132HJJAOCAQ8AMIIBCgKCAQEAgo4deAfr8BeqWOiCsddwMtH5nh8EK2cKIeInpt7LnoCyMsGj1HTP835HpslOURrR6Bgc42V7r6J/MIHqx3+KESTqpcQSe9ll6eUjzaMbIX2GPmy9OnviH6srUgOlDAKhL+/SDh/iv8RfErAPO9cxnoBWUUTyfyes1YRn34KILBdHZoaWk5mteJx9aV4bfA5tGTT6aF8o1NkCX1OUfXiaAD5sqKZV5vbI+QsOUsNshvGfE5JR2EpwZbWH/vRQVusxLURjC51v96ieQ8zUME5LwAQ0TgZcspHTb4Y+KuYRTuDQKuxRUYFeNbvqUGeT2s2sHMmWOQIDAQAB",
"auth-server-url": "https://something.com/auth",
"url": "https://something.com/auth",
"ssl-required": "external",
"resource": "sample-tracker",
"clientId": "sample-tracker",
"credentials": {
"secret": "bnmbsdk87wq"
}
}
I got the mentioned error :Failed to load resource: the server responded with a status of 403 (Forbidden)
To solve this situation you need to configure your keycloak or RedHat Single Sign-On (if you are using the supported version).
Open the keycloak admin console, for example: http://localhost:8180/auth/admin. Then click on Configure > clients and select the account client. The account client must be enabled.
Next, still in Configure > clients, select the client that you are trying to access and click on the scope tab. Add the view-profile role of account application.
The user also needs to have this permission.
There is a resolved issue about this in https://issues.jboss.org/browse/LIVEOAK-204 .
Related
Running an App Engine Java 8 app with Google Cloud Endpoints. I've generated the openapi.json, deployed it to my Endpoints Portal, and can see the API in my portal, with the various methods and resources listed correctly.
I'm running the dev app server locally in IntelliJ using the Cloud Code plugin. When I run it, it opens a browser tab that gives me an Error 403, with the following stack trace (abbreviated):
SEVERE: direct send of a check request service_name: "my-project-redacted.appspot.com"
operation {
operation_id: "11b8f9a6-c9cb-4895-95fb-8bb39176efb9"
operation_name: "1.my_project_dot_appspot_com.MyAPI"
consumer_id: "project:my-project"
start_time {
seconds: 1596075164
nanos: 812000000
}
end_time {
seconds: 1596075164
nanos: 812000000
}
labels {
key: "servicecontrol.googleapis.com/caller_ip"
value: "127.0.0.1"
}
labels {
key: "servicecontrol.googleapis.com/user_agent"
value: "ESP"
}
labels {
key: "servicecontrol.googleapis.com/service_agent"
value: "EF_JAVA/1.0.12"
}
}
failed
endpoints.repackaged.com.google.api.client.http.HttpResponseException: 403
{
"error": {
"code": 403,
"message": "The caller does not have permission",
"errors": [
{
"message": "The caller does not have permission",
"domain": "global",
"reason": "forbidden"
}
],
"status": "PERMISSION_DENIED"
}
}
at endpoints.repackaged.com.google.api.client.googleapis.services.AbstractGoogleClientRequest.newExceptionOnError(AbstractGoogleClientRequest.java:456)
at endpoints.repackaged.com.google.api.client.googleapis.services.AbstractGoogleClientRequest$1.interceptResponse(AbstractGoogleClientRequest.java:321)
at endpoints.repackaged.com.google.api.client.http.HttpRequest.execute(HttpRequest.java:1065)
at endpoints.repackaged.com.google.api.client.googleapis.services.AbstractGoogleClientRequest.executeUnparsed(AbstractGoogleClientRequest.java:419)
at endpoints.repackaged.com.google.api.client.googleapis.services.AbstractGoogleClientRequest.executeUnparsed(AbstractGoogleClientRequest.java:352)
at endpoints.repackaged.com.google.api.client.googleapis.services.AbstractGoogleClientRequest.execute(AbstractGoogleClientRequest.java:469)
at com.google.api.control.Client.check(Client.java:205)
It's worth noting that the API seems to work -- I have the iOS simulator connecting to my local dev app server and making Endpoints calls. I'm just tired of seeing the 403 in my browser every time I start the dev app server, and fear it may portend some similar issue in production when I eventually push this new service.
This error indicates that there is something wrong with the permissions or that the Service Control API is disabled in your project, so in order to fix it you can:
Make sure your service has access to servicecontrol.googleapis.com enabled by running the following command on Cloud Shell:
gcloud services enable servicecontrol.googleapis.com
Double check ENDPOINTS_SERVICE_NAME parameter in your appengine-web.xml file, it should look like this:
<env-var name="ENDPOINTS_SERVICE_NAME" value="$PROJECT"/>
Check if OpenAPI specs are deployed to Cloud, you can check it by running this command on Cloud Shell:
gcloud endpoints configs list --service=$PROJECT
Double check if the Service account running your instance has the proper IAM roles.
We've got an application hosted on a VM in Azure, which is behind a WAF that we've got a lot of trouble with for some users.
Some users are plagued by the HTTP Error 400. The size of the request headers is too long. The application is protected by Azure AD login.
The full repsonse to the browser is:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN""http://www.w3.org/TR/html4/strict.dtd">
{
"data": "<!DOCTYPE HTML PUBLIC \"-//W3C//DTD HTML 4.01//EN\"\"http://www.w3.org/TR/html4/strict.dtd\">\r\n<HTML><HEAD><TITLE>Bad Request</TITLE>\r\n<META HTTP-EQUIV=\"Content-Type\" Content=\"text/html; charset=us-ascii\"></HEAD>\r\n<BODY><h2>Bad Request - Request Too Long</h2>\r\n<hr><p>HTTP Error 400. The size of the request headers is too long.</p>\r\n</BODY></HTML>\r\n",
"status": 400,
"config": {
"method": "GET",
"transformRequest": [
null
],
"transformResponse": [
null
],
"url": "api/datacontext/workbooks/876dac86e00e42878d9e239a8efb00a3/session/start",
"headers": {
"Accept": "application/json, text/plain, */*",
"x-invision-app-language": "EN",
"Authorization": "Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6ImFQY3R3X29kdlJPb0VOZzNWb09sSWgydGlFcyIsImtpZCI6ImFQY3R3X29kdlJPb0VOZzNWb09sSWgydGlFcyJ9.eyJhdWQiOiI2MGMyZDcwNi02M2JmLTRhYzItOGQyZi01M2QzMzM1ZTAwMDIiLCJpc3MiOiJodHRwczovL3N0cy53aW5kb3dzLm5ldC80M2I0MWVlMy01MDllLTRmNDYtOTFmZi1hYWMxNGY5MjAwYTAvIiwiaWF0IjoxNTY5NTg0NTIyLCJuYmYiOjE1Njk1ODQ1MjIsImV4cCI6MTU2OTU4ODQyMiwiYWNyIjoiMSIsImFpbyI6IkFTUUEyLzhNQUFBQWtlMDNycUJycmJoZlNBdDB4SnY4bkF4RzA1V1VPdnd4SjZDUmdVeFdkeGc9IiwiYW1yIjpbInB3ZCJdLCJhcHBpZCI6IjYwYzJkNzA2LTYzYmYtNGFjMi04ZDJmLTUzZDMzMzVlMDAwMiIsImFwcGlkYWNyIjoiMSIsImZhbWlseV9uYW1lIjoiUmV0dmVkdCIsImdpdmVuX25hbWUiOiJFcmlrIiwiaXBhZGRyIjoiMTk0LjI0OC4xNDcuMTMiLCJuYW1lIjoiRXJpayBSZXR2ZWR0Iiwib2lkIjoiMGJjMDUyMDgtZDQ1YS00MTk4LTk3MzItMzZiN2U2MDJiYmYwIiwib25wcmVtX3NpZCI6IlMtMS01LTIxLTEzNDI3OTMzNzAtNDI1NDg1MTE1LTU5NDUyMDk5NS0xODU0Iiwic2NwIjoiRGlyZWN0b3J5LlJlYWQuQWxsIFVzZXIuUmVhZCBVc2VyLlJlYWQuQWxsIFVzZXIuUmVhZEJhc2ljLkFsbCIsInN1YiI6ImJ0M3pIOFNQcjRtMWFqenZJa2ZiMjBnVUZkR3BxblpEYmg3QWJ4M3B5N28iLCJ0aWQiOiI0M2I0MWVlMy01MDllLTRmNDYtOTFmZi1hYWMxNGY5MjAwYTAiLCJ1bmlxdWVfbmFtZSI6ImVyaWsucmV0dmVkdEBjaG9pY2Uubm8iLCJ1cG4iOiJlcmlrLnJldHZlZHRAY2hvaWNlLm5vIiwidXRpIjoiUERYS0FfSl9CRWlmc0tDLVJJbHhBQSIsInZlciI6IjEuMCJ9.aghrUBArpEvvvXBs2MBPTCL2nUPZ3aMCJ-1r3EqB5a9UaqaX7Ego5mSw1gb_68y3KhsGfO7kAv49uCB7cy80kEXV4ES4htLefQmmp-Bx-1Et_w6vstoki9ojWuKP97NsaGlQBjPYCZcbCRptBIZJIr_H71dMuFhAPWYEImcGtOrF2RNQA4AFvlx6WL2dIONHVPar3sjgLWEvFxhPFZsml3Ht3M1OtLj5drAJrkUjgxfV3-00bqCwYCm5_t_BAtxWsd-LZEpjDLpN7nDBFIJF14oFrPB7yXCBM_q-Y4FCCwGE14NoRcUrJNJPYMt5b0LKHEAbIopdq_zmFQ6XnUmcjg"
},
"withCredentials": true
},
"statusText": "Bad Request"
}
The error show up on different paths in the application and seemingly at random. It might work fine for a while then the user gets the error message again. We've narrowed the problem down to beeing the WAF as when we've changed the traffic to flow directly to the IIS webserver the users are seeing none of theese errors. It seems that there's nowhere to change the size limit for the request header that I can find in the WAF. Anyone got any idea as for where to start looking for a solution?
The Azure WAF is configured as follows:
Configure
Tier: WAF
Firewall Status: Enabled
Firewall mode: Detection
There are no exclusions configured.
Global Parameters:
Inspect request body: Off
Rules
Rule set: OWASP 3.0
Advanced rule configuration: Disabled
I am having a bit of trouble setting up my create-react-app application to proxy requests to my test hosting on Microsoft azure. I have set up the proxy in my app's package.json as follows:
"proxy":{
"/api/*":{
"target":"https://mytestbackend.azurewebsites.net",
"secure":false
}
}
I have set up an axios request to be sent to the backend server on azure. It is in a stand-alone .js which I call from one of my react application's events. It looks like this:
import axios from 'axios';
const login = async (username, password) => {
console.log("Username to send is:"+username);
console.log("password to send is:"+password);
let response = await axios.post('/api/user/login', {username:username,password:password});
console.log(response);
};
export {login};
The problem can't be in my react components, because those two console.log() call show that the values entered are being recieved. If I remove the "secure":false setting from package.json, request fails with Http Error: 500. But if I use the secure setting, it fails with a 404 page. Can someone please shed a little light on what am I doing wrong? Can I only use the proxy on "localhost"? The documentation suggests otherwise. Any help is greatly appreciated.
I have verified that CORS is enabled for the domain on which the dev server is running on the Azure Management Portal. And if I do the request by using the backend's URL directly (that is, not using the create-react-app proxy), it works. The problem must be something in the way the proxy is configured.
The response text for the HTTP Errpr 500 which happens when not using secure is :
Proxy error: Could not proxy request /api/user/login from localhost:3000 to https://mytestbackend.azurewebsites.net (undefined).
Additional info: I have also tested by running my Backend locally on my development machine. The error message occurs but the "undefined" in the parenthesis says "UNABLE_TO_VERIFY_LEAF_SIGNATURE". If using "secure: false, I can call the login endpoint successfully, but calls to other endpoints which require authentication fail because the cookie is not sent by axios.
Doing:
curl -v https://mytestbackend.azurewebsites.net/api/user/login
Has this output:
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS alert, Server hello (2):
* SSL certificate problem: unable to get local issuer certificate
* Closing connection #0
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: http://curl.haxx.se/docs/sslcerts.html
curl performs SSL certificate verification by default, using a "bundle"
of Certificate Authority (CA) public keys (CA certs). If the default
bundle file isn't adequate, you can specify an alternate file
using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
the bundle, the certificate verification probably failed due to a
problem with the certificate (it might be expired, or the name might
not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
the -k (or --insecure) option.
create-react-app use WebPackDevServer which uses https://github.com/chimurai/http-proxy-middleware#options
So you can use all the options from the same
Now one key header that is import in such cases of externally hosted server is host. This at times can issues if not correct, see below example
Websocket works on EC2 url but not on ElasticBeanstalk URL
Next is the cookies might be associated with localhost, i checked and they should go without any modification. But you might want to use the cookieDomainRewrite: "" option as well
So the final config I would use is below
"proxy":{
"/api/*":{
"target":"https://mytestbackend.azurewebsites.net",
"secure":false,
"headers": {
"host": "mytestbackend.azurewebsites.net"
},
"cookieDomainRewrite": ""
}
}
Also on your client you want to use the withCredentials:true
let userinfo =await axios.get('/api/secured/userinfo',{withCredentials:true});
Create react app http-proxy-middleware, and should support the full set of options.
Some things I would try:
The path to match may be /api/** instead of /api/* if you want to nest multiple levels deep (eg. for /api/user/login)
You may need to add changeOrigin: true if you're proxying to something remotely (not on localhost)
You will likely want to keep secure: false as you aren't running localhost with https.
So in total, I would try
"proxy":{
"/api/**": {
"target": "https://mytestbackend.azurewebsites.net",
"secure": false,
"changeOrigin": true
}
}
After days of trying unsuccessfully to do this, I finally found a setup that works. Proxy is configured like this:
"proxy": {
"/api/user/login": {
"target": "https://localhost:44396",
"logLevel": "debug",
"secure": false
},
"/api/secured/userinfo": {
"target": "https://localhost:44396",
"secure": false,
"logLevel":"debug",
"secure":false
}
Request to both endpoints on the client have withCredientials:true
try {
await axios({
method:'post',
url:'/api/user/login',
withCredentials:true,
data:
{username:username,password:password}}
);
let userinfo =await axios.get('/api/secured/userinfo',{withCredentials:true});
return userinfo;
As you can see, I've moved to testing on my local dev machine. For whatever reason, this setup refuses to work on the azure-hosted backend. I would have preferred that it work as I originally intended, but at least now I can continue with my project.
I'm trying to deploy my GAE application via termina with the following command: gcloud --project my-project-id --version staging app deploy
It gives me no errors, the only output I get is:
Google Cloud SDK 183.0.0
bq 2.0.27
core 2017.12.08
gsutil 4.28
But the deploy doesn't actually work (I changed some text on one of the API returns just to see if it was changing in the actual URL I access).
Any idea what's going on or how to debug it?
EDIT:
I managed to get an error now:
{
"error": {
"code": 403,
"message": "Operation not allowed",
"status": "PERMISSION_DENIED",
"details": [
{
"#type": "type.googleapis.com/google.rpc.ResourceInfo",
"resourceType": "gae.api",
"description": "The \"appengine.applications.get\" permission is required."
}
]
}
}
DEBUG: (gcloud.app.deploy) Permissions error fetching application
[apps/darwin-ms-transfer]. Please make sure you are using the correct
project ID and that you have permission to view applications on the
project.
And I did check the permissions, I do have the appengine.applications.get permission based on the service account's roles.
We are using a service account to deploy our app to App Engine using Travis.
On every merged PR, Travis pulls the code from our GitHub repository, and pulls a Docker image which contains Google Cloud SDK and executes the gcloud app deploy command. We use a Service Account to perform the deployment with "Project Owner" role.
Everything used to work fine until I added a new service to the project which automates SSL certificate generation and renewal, along with a dispatch.yaml file to route traffic incoming from Let's Encrypt for domain verification. I needed to add more permissions to allow updating the SSL certificates we use for our custom domain. I removed the current service account, and created a new one with a new private key. I created a new role with the required permissions to update and view SSL certificates in addition to the previous permissions (all appengine.* permissions). I assigned the new role and the Project Owner role to the new account. After these changes, the deployment fails with the following error when executing the deploy command:
Permissions error fetching application [apps/hollowverse-c9cad]. Please make sure you are using the correct project ID and that you have permission to view applications on the project.
I used the same service account on my local machine with logging level set to debug. I got this error:
DEBUG: HttpError accessing <https://appengine.googleapis.com/v1/apps/hollowverse-c9cad?alt=json>: response: <{'status': '403', 'content-length': '335', 'x-xss-protection': '1; mode=block', 'x-content-type-options': 'nosniff', 'transfer-encoding': 'chunked', 'vary': 'Origin, X-Origin, Referer', 'server': 'ESF', '-content-encoding': 'gzip', 'cache-control': 'private', 'date': 'Wed, 02 Aug 2017 14:33:50 GMT', 'x-frame-options': 'SAMEORIGIN', 'alt-svc': 'quic=":443"; ma=2592000; v="39,38,37,36,35"', 'content-type': 'application/json; charset=UTF-8'}>, content <{
"error": {
"code": 403,
"message": "Operation not allowed",
"status": "PERMISSION_DENIED",
"details": [
{
"#type": "type.googleapis.com/google.rpc.ResourceInfo",
"resourceType": "gae.api",
"description": "The \"appengine.applications.get\" permission is required."
}
]
}
}
>
DEBUG: (gcloud.beta.app.deploy) Permissions error fetching application [apps/hollowverse-c9cad]. Please make sure you are using the correct project ID and that you have permission to view applications on the project.
The description says that appengine.applications.get is required to perform the deployment. Looking at the permissions granted to the role assigned to the Travis account we use to deploy, appengine.applications.get is clearly granted:
I assigned every possible App Engine and Project role to the account, but deployment still fails with the same error. However, using the default service account, which is automatically created for every new project on GCP, seems to be working.
I removed the current service account, and created a new one with a new private key.
This is where it went wrong. The new account had the same ID as the previous one. Although I could not find this behavior documented anywhere, it looks like that once an ID is used for a service account, it cannot be used again for a new account, even if the previous one is removed.
We created a new account with a new ID (travis2#hollowverse-c9cad.iam.gserviceaccount.com) instead of travis#hollowverse-c9cad.iam.gserviceaccount.com) and the issue is now resolved.