I'm trying to do some request by administration REST API through custom client. Client has proper scopes. I get 403. Same issue when authenticate by user (with proper roles). Everything works fine when I change client to 'admin-cli' and use user authentication. I can not see any difference in configuration.
Is it possible to use admin REST API only through client 'admin-cli' and user authentication?
See this answer to learn how to authorize your client to use the admin rest api : Keycloak Get Users returns 403 forbidden
Related
I am very new to Keycloak server and want to use it to protect my front-end app and the backend rest API which are also open over the internet. So far what I understand and did is to create 2 clients on Keycloack, 1 is for frontend which used Client Protocol(openid-connect) with access type(Public) and then in client side i am using adopter to redirect the users to Keycloak login page and authenticate and get token. Now for the backend(rest-apis), I have created a separate client which again use Client Protocol(openid-connect) but with access type(confidential) and in Authentication Flow: both Browser Flow and Direct Grant Flow are direct grant and after that i get client-id and client-secret to call Keycloak rest api.
Now i want that when user are authenticated from frontend and get the token and send in header request to my rest API, here i call some Keycloak rest api to verify this token by providing client_id and client_secret.
I am using following rest api from Keycloak to verify the token which i generated at frontend:
http://localhost:8120/auth/realms/evva_realm/protocol/openid-connect/token/introspect
but result is getting like that:
{
"active": false
}
It my be i am using some wrong api OR the whole archetecture to verify and protect my backend apis are not correct. Can someone help me to understand where is the problem?
#user565 I found this medium post that works for me. I believe that you can benefit from it as well.
It basically creates two clients, one for the backend, and another for the frontend. The catch is that they share the same roles by leveraging the client scope, roles, and composite roles features.
Hope it helps: https://medium.com/devops-dudes/secure-front-end-react-js-and-back-end-node-js-express-rest-api-with-keycloak-daf159f0a94e
I currently have the following architecture
APP -> API -> KeyCloak
I want the APP to be able to send requests to my API which will then internally proxy certain requests to KeyCloak. For example, I'd like to make a request to the /userinfo endpoint in KeyCloak through my API. If I can figure this out I can then perform more complex features.
APP -> http://api:port/api/userinfo
API -> http://keycloak:port/auth/realms/quartech/protocol/openid-connect/userinfo
I have a valid JWT Bearer token. As I can directly make the request to KeyCloak successfully, however if I attempt to make the request via my API it returns 401. Even though it is using the same JWT Bearer token.
I believe it has something to do with configuring the KeyCloak client to allow requests to come from the API. But so far I haven't been able to figure it out.
I've discovered it required a DNS entry to local development within a Docker container.
I've edited the hosts file and added a 127.0.0.1 keycloak and then al
I have an external endpoint which is going to hit the Azure API gateway and that would route it to the backend API which is protected by IdentityServer4 authorization.
I am getting the access token if I hit it through the Postman client with the interactive UI from IdentityServer.
Is there a way I can get the access token required from the Azure API Management to validate against the IdentityServer4 and append it to the header in the request to the backend API?
Yes it is possible to achieve it through custom policy. You can ask your external API-Client/Consumer to paas in credentials in heaser, and then you write a policy inside inbound to can read those user credentials and do a API request (similar to your postman) and get the access token. You can then append the same token and let your request gets forwarded to backend API.
As per your problem statement, this should work. In case not, you might have to explain your scenario with more description/steps.
Here are some of the reference materials for you, I hope it helps.
https://learn.microsoft.com/en-us/azure/api-management/api-management-advanced-policies#SendRequest
https://learn.microsoft.com/en-us/azure/api-management/api-management-sample-send-request
Postman has a luxury of a human user seeing the UI and authorizing API access and IdentityServer4 to issue a token for Postman. There is no such luxury when call is being processed by APIM server, as you could send request for token to IdentityServer4, but who would be presented UI to authorize the action?
The only way is to provision some sort of secret to APIM (header, query, certificate) that would be recognized by IdentityServer4 to allow it issuing tokens for APIM. If such secred is available you could use send-request policy to make a call to IdentityServer4 and obtain required token.
Or make sure that every request to APIM has a token already.
We have a system with three layer includes API Server (Backend), Client Web Site, and End User. Now, the Authentication occurs on API Server, which be done in two case. In one case, Client Web Site call API directly using a token (Client Token) which get from a service based on user/pass and in another case, besides End User login into API Server using Client Web Site, but authentication occurred on API Server other than Client Web Site. Client Site get another token which named as Auth Token (for end user calling), then call API that End User requested by sending two mentioned tokens. By using Client and Auth Tokens, API Server checks whether client and end User are logged in respectively or not. Entities and their relations are illustrated in here
I want to use API Manager as a gateway between API Server and Client Site and manage authentication process with it.
How can I implement this scenario using WSO2 API Manger?
thanks for your response!
Extending the previous answer..
If the backend is behind the API manager (adviced), the API maanger can pass the client/user/application information to the backend as JWT token. So indeed, that's a good use case to use the API Manager
Edit: extending answer based on comments
in one scenario when a user login to client website, it pass the user
& pass to API server. therefore, API server checks the validity of U&P
Indeed, using the default OAuth (code or password profile) will work.
and creates a Auth token as well creates a session for user.
Almost good. A token is returned, there's no user session in API Manager. All authorization is based on the token provided.
of session, that whether Client web site and end user
are logged in or not. the checking process performed by two tokens
Nope. The APIM doesn't check for any session. It checks only the OAuth (Bearer) token.
and in another scenario client web site call API directly without any
request from end user.in this scenario auth token is not exist
The web site (lets call it Application) can authenticate using its own credentials (so called client_credentials profile). It may receive its own OAuth application token.
The same feature is supported in APIM. You can simply get rid of authentication login from your backend (or replace with a simple one) and use APIM Authentication.
APIM uses OAuth2. To cater your requirement, you can use different grant types. For client website, you can use client credentials grant type, and for end users, you can use other grant types such as password or authorization code.
For more details read:
https://docs.wso2.com/display/AM210/Quick+Start+Guide
https://docs.wso2.com/display/AM210/Token+API
We are currently analyzing the API gateway for our microservices and Kong is one of the possible candidate. We discovered that Kong support several plugins for authentication but the all based on users stored in Kong database itself. We need to delegate this responsibility to our custom auth HTTP service and don't want to add these users in API gateway database.
It's possible to do this with some code around, instead of using the OpenID connect plugin; in effect you need to implement an Authorization Server which talks to Kong via the Admin (8001) port and authorizes the use of an API with externally given User Ids.
In short, it goes as follows (here for the Authorization Code grant):
Instead of asking Kong directly for tokens, hit the Authorization Server with a request to get a token for a specific API (either hard coded or parameterized, depending on what you need), and include the client ID of the application which needs access in the call (you implement the /authorize end point in fact)
The Authorization Server now needs to authenticate with whatever IdP you need, so that you have the authenticated user inside your Authorization Server
Now get the provision code for your API via the Kong Admin API, and hit the /oauth2/authorize end point of your Kong Gateway (port 8443), including the provision key; note that you may need to look up the client secret for the application client id also via the Admin API to make this work
Include client id, client secret, authenticated user id (from your custom IdP) and optinally scope in the POST to /oauth2/authorize; these values will be added to backend calls to your API using the access token the application can now claim using the authorization code
Kong will give you an Authorization Code back, which you pass back to the application via an 302 redirect (you will need to read the OAuth2 spec for this)
The application uses its client and secret, with the authorization code, to get the access token (and refresh token) from Kong's port 8443, URL /oauth2/token.
It sounds more involved than it is in the end. I did this for wicked.haufe.io, which is based on Kong and node.js, and adds an open source developer portal to Kong. There's a lot of code in the following two projects which show what can be done to integrate with any IdP:
https://github.com/apim-haufe-io/wicked.portal-kong-adapter
https://github.com/Haufe-Lexware/wicked.auth-passport
https://github.com/Haufe-Lexware/wicked.auth-saml
We're currently investigating to see whether we can also add a default authorization server to wicked, but right now you'd have to roll/fork your own.
Maybe this helps, Martin
Check out Kong's OpenID Connect plugin getkong.org/plugins/openid-connect-rp - it connects to external identity and auth systems.