How do I connect to Jhipster registry using Eureka endpoints?
I followed this blog.
But Jhipster registry doesn't to recognise sidecar and the registration fails with
404 Bad request.
All I had to do was to frame the defaultZone using jhipster username and password http://admin:admin#localhost:8761/eureka/
The 404 error is because of jhipster security for any request coming on /eureka/**
Related
I've set up my new gateway and a microservice for testing purpose.
The microservice has a single entity with only one field.
The gateway recognize the microservice in gateway Tab of the administration panel over the web interface, but in the URL i see /services/test/** .
If i try to use the swagger integrated in the interface the request is generated with the same url.
And i'm getting always error 401.
I didn't find something useful in other questions.
I just want to know how to remove that /services in the URL because the test miscroservice is mapped like : localhost:8080/test/api/tests
I'm using jHipster 6.0.1
I'm using JWT Auth
Everything is build with Maven.
Is it correct that the eureka and config endpoints provided by the jhipster-registry are not secured or am I doing something wrong?
I started the jhipster-registry (latest docker image) with oauth2 profile and a keycloak configuration. When I try calling the eureka/apps REST endpoint without basic authentication I get the login page html of keycloak - that's ok. If I send the basic authentication header I always get a result - even if I send it empty or with a user that does not exist.
Is this the intended behaviour or am I missing some configuration?
Thanks!
Kristina
I use jhipster 5.4.1. simple monolithic app with OAuth2. I try with both angluar or React generation.
It works with Keycloak local test.
I follow all instructions from https://www.jhipster.tech/security/ for Okta.
And then, I have error 404 when jhispter app trying to access okta
https://dev-796955-admin.oktapreview.com/error/404?fromURI=%2Foauth2%2Fdefault%2Fv1%2Fauthorize%3Fclient_id%My okta client id is here%26redirect_uri%3Dhttp%3A%2F%2Flocalhost%3A8080%2Flogin%26response_type%3Dcode%26scope%3Dopenid%2520profile%2520email%26state%some state
Are Instructions :
specify http://localhost:8080 as a Base URI and
http://localhost:8080/login as a Login Redirect URI
in okta web app correct ?
Remove the “-admin” from your Okta URL and everything should work.
Can anybody point me in a direction for configuring the jhipster gateway to use an external OpenID Connect (OIDC) provider instead of bundling all the UAA stuff? I know of the jhipster UAA server, but that seems to be a standalone auth server.
My use case is that my (many) different jhipster microservice projects will have their authentication and JWT generation stuff handled by an external OIDC provider - not the jhipster gateway itself.
Btw, I'm aware of these projects:
github.com/jhipster/jhipster-openid-connect
github.com/sdoxsee/jhipster-openid-connect-microservices
And I've read through this lengthy discussion which seems to conclude that and OpenId Connect alternative is in the making:
https://github.com/jhipster/jhipster-experimental-microservices/issues/3
I have some ideas:
Set up a microservices stack to use the UAA server. Then, in some way, instead of using the jhipster UAA server, point at my external OIDC provider.
Look at what mraible has done with regards to the Stormpath (and soon to come Okta) subgenerator.
Experiment with "social logins"(jhipster.github.io/tips/012_tip_add_new_spring_social_connector.html)
Would anybody like to discuss?
You may be already aware but OpenID Connect support has been merged and is due to come out in the next jhipster release (4.10.0?)
Here's the merged pull request and more support is coming.
What's the difference between Jhipster UAA and cloud foundry UAA, are they compatible with each other?
This doesn't describe it entirely but from http://jhipster.github.io/using-uaa/
JHipster UAA is a user accounting and authorizing service for securing JHipster microservices using the OAuth2 authorization protocol.
To clearly distinct JHipster UAA from other “UAA”s as cloudfoundrys UAA, JHipster UAA is an fully configured OAuth2 authorization server with the users and roles endpoints inside, wrapped into a usual JHipster application. This allows the developer to deeply configure every aspect of his user domain, without restricting on policies by other ready-to-use UAAs.
I'd say that JHipster UAA is simply a spring-boot app (tweaks a-la jhipster...but without the angular client-side) that uses the #EnableAuthorizationServer to make the UAA app to serve as an oauth2 authorization server--granting tokens to client apps (jhipster gateways in this case) to call resource servers and providing the public key that resource servers would use to verify tokens. JHipster UAA is predominantly a server-side app at the moment. It has the authorization server code and stores the actual user information but has no UI itself for managing those users (the UI to manage it is duplicated on each gateway app). JHipster's UAA also can't do single sign on (SSO) (unlike cloudfoundry uaa) because it doesn't expose a login endpoint in the browser needed to create the session on the authorization server to enable SSO between client (or gateway) apps.
Cloudfoundry's UAA is much more comprehensive but does much the same thing (as far as doing what oauth2 authorization servers do). As it stands right now, cloudfoundry is a more mature and flexible app but isn't integrated with jhipster out of the box...yet.
I currently still have an old public github repo that integrates jhipster with cloudfoundry uaa but jhipster has changed a lot since. https://github.com/sdoxsee/jhipster-openid-connect-microservices