Folks i am a little confused when I set up a service a route and the openid connect plugin and try to access the endpoint (authn uri) I get a 302 - when I try this from postman or soupui I get no route or api message
Have you found an answer to this question yet? Since OpenID Connect is an enterprise plugin you might have access to support via the support portal as well. Just want to make sure you’re not stuck if you have access to support!
Then EE OpenID Connect Plugin falls back to authorization code flow if you don’t give it any credentials (that it can use) on request. If you remove authorization_code from plugins config.auth_methods then it will give you 401 — Unauthorized (as there is no fallback anymore).
Thanks - its actually pretty snazzy once you get it working - basically i am protecting three web services
authz autha and authk … kinda neat now I have the first latch - via keycloak and glue and cognito federated together and offering fallback on each other , the second latch verification via abstracted authz/openid connect end point for token verification and jwt introspection using scope and claims authorization - uma basically
kong needs to do some work on its jwe jws compatability - im having to offload this all of the jws and jwe work out to gluu via abastracted endpoints , auditing is done via keycloak and amazon - off to kafka and then the elkstack but its really neat to see all this opensource working together - i can use the comumunity fgateway and the nokia plugin to do same thing but im going to use elasticache to make it fly and I thought the enterprise edition was worth demoing
I’m sorry about the trouble you are having. Let me try to clarify your questions.
a service seems to be a placeholder for an outgoing endpoint but maybe maybe no.
Kong routes requests from a user to a Service. In general, Services are usually APIs to which Kong acts as a proxy.
There are a couple wrinkles to it:
when doing load balancing, a single Service can end up pointing to several upstream services/machines.
when using custom plugins, requests can potentially be sent off anywhere.
We use the term “endpoint” to refer to “paths inside a Service”, not for servers.
what is a route
A single Kong instance can be used to proxy to many different Services. When a request arrives, Kong needs to determine to which Service it should sent it to.
Routes are the rules by which Kong makes these decisions: they do the “mapping”. Each route belongs to a single service, and a service can have many routes.
a diagram would help
Ok. So this is how Routes relate to Services.
+---------- Kong ----------+
"b" | Route a ----> Service 1 |
client -----> | Route b ----> Service 1 | ----> Service 1
| Route c ----> Service 2 |
+--------------------------+
Since Kong can make changes to a request before sending it to the service, and changes to the responses before sending them back to the users, we differentiate between “requests” and “service requests”. And same with “response” and “service responses”
1. request 2. service request
--------------> --------------->
user Kong Service
<-------------- <---------------
4. response 3. service response
if I create an api , then a service with the same path who wins
API is a deprecated entity. We split API entity to Route and Service. Think about Service being upstream_url of API entity. Route will be matched before API so that you can migrate from APIs to Routes and Services without needing to delete APIs.
Firstly thank-you both for the replies this clears up just about everything ,
I guess I really need to check what algorithms and cypher mechanism are used and currently supported
before making bold statements …
Signature verification should work with RS256, RS512, PS256, PS384, PS512, ES256, ES384, ES512, HS256, HS384, HS512. I would use asymmetric crypto as it makes it easier to share and rotate public keys (vs. shared secret).
At the moment we only support compact serialization of JWS.