Let's suppose a scenario where we have two Orions deployed in different cloud infrastructures. These Orions are behind a PEP (Wilma) each, with no posibilty of accesing them without autentication.
Would it be possible to federate these Orions through the PEP?
If the Orion2 (O2) is the context provider of Orion1 (O1) when an O1 user request a queryContext to O1 will the access token propagate to O2?
Yes, the access token in x-auth-header is propagated in forwarded requests so the scenario you propose (named "pull" federation) should work.
EDIT: is the CB receiving the propagated request uses a PEP governed by the same security framework of the sending CB (in other words, the PEP of both CBs share the same IDM/AC instance) then federation is automatic. If the CBs doesn't share the same IDM/AC instance then you need some piece in the middle (a proxy) able to translate the x-auth-header valid in the sending CB to a x-auth-token valid in the receiving CB (the proxy should interact with the IDM governing the receiving CB).
Related
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
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)
We have a micro services architecture and we are having some discussions about how to expose internal errors to the client.
Here's an example:
Let's suppose we have 3 services, service A, B and C.
When the client sends a request to the service A, which is public, this service sends a request to service B that sends a request to service C (which are internal and needs authentication, but the credentials are stored internally like environment variables, they are not send by the client).
And for some reason the communication between B and C receives a 401 (could be 422, 403 or any client related errors), which means that the request was not authorized.
Something like that:
The communication between B and C is internal, the user don't know about these services. Should I expose our internal structure sending a 401 to the client? Given it's not the client's fault? Should I send a 500?
It's better to avoid exposing 500 status explicitly but in some cases it's necessary. A user works with your system not with particular service and for him it doesn't matter what is inside. Internal system implementation can vary but user interaction can stay the same.
Let's A will be for instance a e-commerce service, B - billing service and C - billing gateway. User buys a product via A which send billing request to B and B communicates with C to perform transaction. 401 between B and C can be for different reasons. If it is simply internal configuration problem (not updated password, expired certificate and so on) it is an internal system bug and you need to tell user that service is unavailable now or something like that, not to pass all internal error details of course. You can use 5xx code in this case. Perhaps service B can put request to some kind of queue and tell service A that's everything is OK, your request will be processed later. But if it is because of user tries to use bad credit card or don't have enough money (not authorized request) A needs to show the proper message and 4xx response code.
In general a service exposes resources and it doesn't matter how many internal or external services, databases, data sources and so on are behind it. Perhaps 401 between B and C means for B to go to D service (C alternate) and A service shouldn't know about 401 at all. So, it depends on what you need to expose to user and how you need to handle different cases.
Your diagram makes little sense. The incoming call is not 200 until it returns to the user successfully, after all internal services are called.
If the authentication between B and C is internal (server to server auth), then you have an internal error, and 502 is a sane choice to return to A. Of course, you might decide to retry in server A, as you got a 502 from B, but it's pointless because it's an expired token. So you may decide as policy that internal 401s should be escalated back to A. Or you may find attaching metadata in the 502 error response body assists a retrying mechanism. Anyway, server-server auth shouldn't be failing where it is a valid call.
So ... if C's authentication is working on the user's supplied token, then the user's authentication ran out during the call (rare, but happens) - in this case the token should have been extended elsewhere in the system prior to this call (probably in A's call to SSO). But it wasn't, so return 401 to where-ever in the application redirects to the login page.
We have come across similar problem, need your help to resolve this.
Can you please either let us know your contact number so that we can reach out to you or if you can provide your script if possible so that we can refer to
Here is the problem we are stuck with:
I am trying to test a Rest service through HTTP sampler using Jmeter. Not sure how to capture token from the sampler generates a token and to use this token for authorization in the header manager of another HTTP.
Loadrunner is not displaying the web address when trying to enter in the truclient browser. Below is the problem as this web address automatically redirect to another web address which is the authentication server.
Can you please suggest another solution for the below issue?
Here is the exact scenario we are trying to achieve
we want to loadtest the portal however due to redirect and different authentication method being used we are unable to do it using truclient protocol in loadrunner. Also tried Multiple protocol selecting LDAP, SMTP, HTTP/HTML etc but no luck.**
Thank You,
Sonny
JMETER is going to architecturally be the HTTP protocol layer equivalent with LoadRunner, with the exception of the number of threads per browser emulation.
In contrast to the code request, I want to architecturally visualize the problem. You mention redirect, is this an HTTP 301/302 redirect or one which is handled with information passed back to the client, processed on the client and then redirected to another host? You mention dynamic authentication via header token, have you examined the web_add_header() and web_add_auto_header() in Laodrunner web virtual users for passing of extra header messages, including ones which have been correlated from previous requests, such as the token being passed back as you note?
This authentication mechanism is based upon? LDAP? Kerberos? Windows Integrated Authentication? Simple Authentication based upon username/password in header? Can you be architecturally more specific and when this comes into play, such as from the first request to gain access to the test environment through the firewall or from a nth request to gain access within a business process?
You mention RESTFul services. These can be transport independent, such as being passed over SMTP using a mailbox to broker the passing of data between client and server, or over HTTP similar to SOAP messages. Do you have architectural clarity on this? Could it be that you need to provide mailbox authentication across SMTP and POP3 to send and receive?
I have a high-level/conceptual question about Shibboleth.
I'm working on the front-end (running Drupal) of a data-driven web app. End-users interact with the front-end to construct data queries, which makes background requests to a caching/archiving data proxy (the "data retrieval service"), which in turn either delivers data from its cache or goes out and queries still more services ("out there") which have desired data. So far so good... it is ornate, but only as ornate as the problem we're trying to solve.
Here's the wrinkle: Some of services queried by the data retrieval service want to implement user-level authentication, so that some users may access their data, but others cannot. For organizational reasons, our identity and authentication mechanism is likely to be Shibboleth.
So, here's my scenario: a user logs in to the frontend using Shibboleth. Now, can my frontend, and in turn, the data retrieval service, authenticate against against external services as the user? And if so, how does that work in practice (what authentication data gets passed from server to server)?
Yes it can - you service has to exist in the identity provider (how it is set up is up to you)