I'm creating a new application with jhipster generator v7.8.1 with the following options:
Monolithic application
Spring WebFlux? No
authentication: OAuth 2.0 / OIDC Authentication
database: mongodb
cache: Ehcache
Maven
monitor and scale your application? No
other technologies: Elasticsearch as search engine
Framework for client: React
Do you want to generate the admin UI? Yes
However, the user management screens are not being generated as they used to be. What could be happening?
There is no user management generated when using OAuth / OIDC. We expect you to manage your users on your identity provider (Keycloak, Okta, or Auth0).
Related
If I deploy a spring boot application as a azure app, I can externalize the authentication by
using azure API management and configuring oauth2 etc
using the authentication options of azure app service.
As such I don't need to configure any authentication in my spring boot application.
All that works fine and I can find a lot of info about that. What I cannot find is: how do I retrieve the logged on user in my application in such case? How is that information passed to my application?
If you are using oauth2 you should be able to fetch the username from JWT token/via an api call. You can refer this link which tells you how to read jwt token. Once you have the username then you can add it to a custom header and pass to your backend application. Follow this link to understand how to add custom header to your request in api manager to be passed to your back end
How to use loopback4 application authentication strategy with keycloak or keycloak-connect .
Keycloak provides steps w.r.t express application but would like to use it in loopback4.
Ref : https://www.keycloak.org/docs/latest/securing_apps/#_nodejs_adapter
keycloak-backend npm library provides token verification methods(online and offline) for authentication alone. Offline method requires a public key which can be, in most cases, retrieved from https://{keycloak-domain}/auth/realms/{realm}.
Our project have a requirement to implement SSO in legacy application(Running in Weblogic) and New microservices/angular application - using PF OpenId/OAuth 2.0.
New application is using OpenId/OAuth 2.0 end point to authenticate/authorise. When I navigate to legacy application from new application , I should be able to pass the jwt token without asking for login and create user session in legacy. Also when I login first in legacy application running in Weblogic then I should be able to authenticate the user using openId/OAuth 2.0 and pass the token to new application.
Question: Is it okay to call the OpenId/OAuth 2.0 end point configured in PF from weblogic and create the user session or PF has any weblogic integration kit to achieve this?
Yes, I would suggest using Weblogic's OIDC functionality. Ping used to have a Weblogic integration kit, but with the addition of OAuth and OIDC to the Weblogic identity provider functionality, you're far better off using it than one of the kits.
If you don't want to use that functionality, another avenue is a WAM tool (such as Ping's PingAccess) or some functionality in a proxy like nginx or Apache in front of your application servers.
I couldn't find answers about using both frameworks working together.
We are planning to build an identity provider service (like Google Account) which is used to authenticate a user and provide OpenId Connection protocol to a Rely Party app. We have existing projects built in ServiceStack which work all fine. However, ServiceStack seems not to be compatible with IdentityServer4 in regards to authenticating a user. ServiceStack has its own authentication mechanism and IdentityServer4 relies on Asp.NET Identity Model. If I sign in via ASP.NET Identity Model, ServiceStack APIs may not recognize the user has signed in. And vice versa.
Is there any suggestion about this is a dead end or some solution that may make them work together?
The mvcidentityserver Project Template contains a pre-configured ServiceStack + IdentityServer4 starting project template:
$ dotnet tool install -g x
$ x new mvcidentityserver ProjectName
See the Using IdentityServer4 Auth in ServiceStack docs for more info on ServiceStack + IdentityServer4 integration.
In addition there are a couple of options available from the ServiceStack community:
Using IdentityServer 4 with ServiceStack and Angular
servicestack-authentication-identityserver
JwtAuthProviderReaderPatchedForIdentityServer4.cs - description
Here is what I am trying to accomplish -
A native application which is going to be run on a system where I cannot involve the user to login but I want to access web services secured behind AAD using a bearer token. There are two options -
Use a certificate based flow (which I want to avoid for few reasons
specific to my project)
Use the client secret
Issue I am running into:
When I call acquiretokenasync using the Native AAD application's client ID and a client credential built using the AAD web application's (which the native app has permissions to) client secret, I get the following error -
{"AADSTS70002: Error validating credentials. AADSTS50012: Invalid client secret is provided.\r\nTrace ID: f52cc954-2674-47ee-9a7b-094451b05c7c\r\nCorrelation ID: 1ba8ac64-cc4a-4ff7-83d6-a333504459d6\r\nTimestamp: 2016-08-20 01:45:08Z"}
So given that the client secret is indeed correct (which I am positive about), what could be the real issue behind this error?
Thanks in advance for your help :)
You can't use the native application client ID and web application client credential (client secret). The native application has no associated secret, only the web application has. Native applications are assumed to run on insecure hosts, such as the desktops and smartphones. Client secrets would become too fragile.
For more information on how to authenticate a native application and access resources, take a look at these articles:
Authentication Scenarios - Native Application to Web API
Developing Native Client Applications
There are two types of application which we can register in Azure Active Directory.
Select Native for client applications that are installed locally on
a device. This setting is used for OAuth public native clients.
Select Web app/API for client applications and resource/API applications that are installed on a secure server. This setting is
used for OAuth confidential web clients and public user-agent-based
clients. The same application can also expose both a client and
resource/API.
Native applications are public clients in OAuth2 parlance. Those apps are meant to run on a device and aren't trusted to maintain a secret - hence, their entry in the directory does not have the corresponding property. Without a secret, there is no way to assert the identity of the app - hence such apps cannot gain app level permissions and the portal UX reflects that. Conversely web apps are, again in OAuth2 parlance, confidential clients. They can get delegated tokens for their users, but they can also use client credentials to get tokens as themselves. Native apps can obtain tokens for the user via the OAuth2 authorization grant.
Refer this article further.