Using REST API method GET /{realm}/clients we may list clients information.
To do this in keycloak 20.0.0, all you need to have is:
access token (for clients -- service account)
role realm-management/view-clients
Clients is separated applications, that use single SSO, isn't?
Or is this role so powerful?
Filtered examples of responses for mentioned method:
keycloak:18.0.0: response-18.json
keycloak:20.0.0: response-20.json
All scripts to reproduce in gist: https://gist.github.com/SilentSpammer/7d633e10530679b2504eac3ee393fc38
Related
I'm working with a service that will forward data to a URL of your choosing via HTTP POST requests.
Is there a simple way to publish to a Pubsub topic with a POST? The service I'm using (Hologram.io's Advanced Webhook Builder) can't store any files, so I can't upload a Google Cloud service account JSON key file.
Thanks,
Ryan
You have 2 challenges in your use cases:
Format
Authentication
Format
You need to customize the webhook to comply with the PubSub format. Some webhoock are enough customizable for that but it's not the case of all. If you can't customize the webhook call as PubSub expect, you need to use an intermediary layer (Cloud Functions or Cloud Run for example)
Authentication
Directly to PubSub or with an intermediary layer, the situation is the same: the requester (the webhook) needs to be authenticated and authorized to access to the Google Cloud service.
One of the bad, and possible, practice, is to set allUsers authorized to access your resources. Here an example with a PubSub topic
Don't do that. Even if you increase "your" process security by defining a schema (and thus to reject all the messages that aren't compliant with this schema), letting a resource publicly, and without authentication, accessible on the wild internet is criminal!
In the webhook context (I had this case previously in my company) I recommend you to use a static authentication (a long lived authentication header; not a short lived (1h) as a Google OAuth2 token); an API Key for example. It's not perfect, because in case of API Key leak, the bad actors will be able to use this breach for a long time (rotate as soon as you can your API Keys!), but it's safer than nothing!
I wrote a pretty old article on this use case (with ESPv2 and Cloud Run), but the principle, and the configuration, is almost the same on API Gateway, a Google Cloud manage services. In the article, I create a proxy for Cloud Run, Cloud Functions and App Engine, but you can do the same thing with PubSub by setting the correct target URL.
use case
in icCube
one server instance
icCube users only need to access the reporting
icCube is used to for a standard reporting solution for an industry vertical and can be used by multiple clients, each having their own (copy of the) structures that work with their own data
a client can grant one or more users access to their own dashboards in icCube
authorization requirement
it should be possible to link authorization to the client's identity
management system (such as AD)
for others, it should be possible to assign a local admin at the client that can give access to their own environment to whom they wih
for the rest, it should be possible for a centralized admin to maintain access
a perfect job for ...
keycloak
keycloak needs for each of the requirements a seperate realm with client (see picture)
The icCube documentation only makes mention of one Realm & client.
the question
Is it possible to use multiple keycloak realms & clients with one instance of icCube?
See also icCube documentation on keycloak integration
Right now this is not possible.
The keycloak.json file is used to connect to a Keycloak server that is going to authenticate the HTTP request. So you would need somehow a way to determine which keycloak.json file to use based on the HTTP request before using it meaning having different URL and/or URLs with a specific parameter.
Possibly the multi-tenant support could be extended to be able to configure an authentication logic per tenant with the same constraint about the URL value.
Hope that helps.
Question
Can I get nginx to call another microservice inside of AKS k8s prior to it routing to the requested api? - the goal being to speed up requests (fewer hops) and simplify build and deployment (fewer services).
Explanation
In our currently deployed Azure AKS (Kubernetes) cluster, we have an additional service I was hoping to replace with nginx. It's a routing microservice that calls out to a identity API prior to doing the routing.
The reason is a common one I'd imagine, we recieve some kind of authentication token via some pre-defined header(s) (the standard Authorization header, or sometimes some bespoke ones used for debug tokens, and impersonation), we call from the routing API into the identity API with those pre-defined headers and get a user identity object in return.
We then pass on this basic user identity object into the microservices so they have quick and easy access to the user and roles.
A brief explanation would be:
Nginx receives a request, off-loads SSL and route to the requested service.
Routing API takes the authorization headers and makes a call to the Identity API.
Identity API validations the authorization information and returns either an authorization error (when auth fails), or a serialized user identity object.
Router API either returns there and then, for failure, or routes to the requested microservice (by cracking the request path), and attaches the user identity object as a header.
Requested microservice can then turn that user identity object into a Claims Principal in the case of .NET Core for example.
There are obviously options for merging the Router.API and the UserIdentity.API, but keeping the separation of concerns seems like a better move. I'd just to remove the Route.API, in-order to maintain that separation, but get nginx to do that work for me.
ProxyKit (https://github.com/damianh/ProxyKit) could be a good alternative to nginx - it allows you to easily add custom logic to certain requests (for example I lookup API keys based on a tenant in URL) and you can cache the responses using CacheCow (see a recipe in ProxyKit source)
I have generated JAX-RS stubs for a REST service using Swagger and want to set up the security.
The security side is very new to me and I would like to use standards as far as possible. (In the past, for other J2EE applications, I have used Filters to handle Authentication which put User objects into a Session. As I understand it, Sessions should be avoided for REST.)
There are 4 types of user who will access the services
Customers and business partners (Authentication via oAuth or similar)
Employees (Authentication via NTLM & LDAP)
Developers (Mock authentication/authorisation of some kind)
Integration test (JUnit with pre-defined users and roles)
Is it possible to define a security mechanism which would handle all of these users?
How would I use the Swagger security directives?
Am I making this more complicated than it needs to be?
You could use an open source API gateway like Tyk? Here’s a link to some handy info on API Security in the tyk docs.
And here is a blog post that describes taking a layered approach to API Security that goes beyond the gateway.
Disclosure: I work for Tyk!
I have seen many different posts regarding different solutions for authenticating a RESTful API and I have some questions, given this current scenario.
I've built a REST API that will allow clients of my software service (we are a B2B company) to access resources programmatically. Now that I've got the API working properly, I'd like to secure it in the most standardized way possible. I need to allow access to certain resources based on the caller of the API. That is to say, not all users of the API can access all resources.
I have URLS available in the following formats:
https://mydomain/api/students
https://mydomain/api/students/s123
https://mydomain/api/students/s123/classes
https://mydomain/api/students/s123/classes/c456
So far I've come up with these possible solutions:
Provide a unique key to each client that they can use to ultimately generate an encrypted token that will be passed as a GET parameter at the end of each REST call to (re)-authenticate every single request. Is this approach too expensive
https://mydomain.com/api/students/s123?token=abc123
Provide a value in the HTTP Authorization Header as seen here. Is this almost the same as #1? (Except I can't paste a URL into the browser) Do people use these headers anymore?
Use OAuth 2 (which I'm still a bit unclear on). Does OAuth 2 actually authenticate the client as a logged in user? And doesn't that go against the spirit of a REST API being stateless? I was hoping OAuth was the proper solution for me (since it's a public standard), but after reading up on it a little bit, I'm not so sure. Is it overkill and/or improper for REST API calls?
My goal is to provide an API that will not have to be changed for each client that wants to consume the API, but rather that I can provide a standard documentation made available to all of our clients.
I'll be happy to post additional details if I've been unclear.
There are 2 type of clients you probably want to prepare your API:
trusted clients - Which are written by you. They can have the username and password of the actual user, and they can send that data to your server with every request, possibly in a HTTP auth header. All you need is an encrypted connection by them.
3rd party clients - Which are written by some random developer. You can register them in your service and add a unique API key to each of them. After that if an user wants to use their services, you have to show her a prompt in which she can allow access to the 3rd party client. After that the 3rd party client will be assigned to the user's account with the given permissions and it will get an user specific access token. So when the client sends its API key and the user specific token along with the request, then it sends the requests in the name of the user.
OAuth can help you to control the second situation.
Your URLs do not have a meaning to the clients. By REST you have to decouple the clients from the URL structure by sending links annotated with semantics (e.g. link relations). So your documentation does not have to contain anything about the URL structure (maybe it can be useful for server side debug, but nothing more). You have to talk about different types of links. By generating these links on server side, you can check the permissions of the actual user (or 3rd party client) and skip the links which she does not have permission to follow.