here is my specifications
Some users of my application are employees of the company and must use the Active Directory to connect.
Others are external users who are referenced in the application database.
Once authenticated, the user receives a JWT token and it's this token which gives him access (RBAC) to the services of the application.
So I have to implement an authentication system that manages three methods, LDAP, JDBC, JWT.
How can we do that with quarkus ?
With Wildfly my authentication module tries to validate the login successively on a list of realms.
A simple solution seem be to use keycloak to aggregate different providers
But I'm asked preferably to have only one executable to deploy.
So I'm looking for a standalone solution.
Thank
Related
I have a need to implement Open ID Connect in an ASP.NET Core 5 web app for authentication at an organization. I cannot test against the identity provider as this org has their own internal one.
I thought Open ID Connect (oidc) was a standard - yet when I look at docs and sample code for the various providers around, they all either have something provided with ASP.NET or I have to install their package.
For example, to use Google, the ASP.NET Core docs say to use services.AddAuthentication().AddGoogle(). For Facebook, it says to use .AddFacebook().
For Auth0, it wants me to install the package Auth0.AspNetCore.Authentication.
Is it not possible to just add OIDC authentication to my app and have it work with any OIDC provider and just change a configuration file to specify the authority URL, Client ID, Client Secret?
I'm confused about why I need these provider-specific calls and packages.
Architecturally, tieing an app to a single form of authentication is entirely wrong, as you suggest. These packages have limited use, perhaps for very simple use cases.
The original OAuth 2.0 spec from RFC6749, from 2012, describes how the OAuth framework is designed, to externalize difficult security from your apps:
The client only implements a code flow
It redirects to an authorization server (AS)
The AS can authenticate users in a myriad of potential ways, including many identity providers
After authentication (and possibly consent) the AS issues tokens to your apps
Tokens enable authorization in your APIs in a myriad of potential ways
Once you've implemented a code flow in your app, your set of users can potentially login in many ways, with zero code changes in the app:
Password sign in (a default option)
Multi-factor authentication (in a dynamic way potentially)
Cloud platform identity providers (for engineering staff)
CRM identity provider (for client focused staff)
SAML identity providet (for users from business partners)
Webauthn, Passkeys and Digital wallets (for some of your customers)
Unless you have a very good reason, stick to OpenID Connect standards based code flows in clients. You can do all of the above using the Microsoft libraries. Auth0 have good libraries also - just make sure you use the standards based ones.
OpenID Connect is an open standard that organisations use to
authenticate users. IdPs use this so that users can sign in to the IdP
From this blog.
And about the OIDC protocol, it allows you to authenticate users, and is designed for users to sign in many websites with only one account, usually it's a social/work account. This is only a protocol and you have to use an implement such as Google/Azure authentication to allow your users to sign in with their specific account.
By the way, since the implements are from different companies, so the configuration in our codes are different and they required different nuget packages like Microsoft.Identity.Web. For example, when using Azure, we need to set such as client id, client secret, tenant id, domain, redirect url... in appsettings.json.
I have to design an IAM solution for a NodeJS microservice using Auth0. Objective is to allow third party mobile application users to access this microservice.
I understand OAuth and OpenID connect solution and one simple solution is third party application accesses APIs as a client using client credentials workflow.
Solution I have to design is allowing users to login and authenticate using their Enterprise IdP connected to our Auth0 Server. So that we can implement authorization and access control at user level.
At the same time customer application needs to be kept agnostic of Auth0 service.
What I mean by it is client should not be required to add any logic in their application for accommodating our Auth0 domain like we have in first party React application. user once logged in to customer application should get access to our API also by using SSO capability. I have read some documents about configuring customer IdP with our Auth0 server acting as a SAML SP. Still I could not understand hows of it and will Auth0 create an OAuth access token in this scenario.
I realise this requires an app to intermediate between customer's mobile app and our API service. Still, I am not able to understand data flow and communication between various components.
Also, I am not sure it is a common situation or requirement? If it is is there any technical term for it? This not seem like a standard B2B scenario.
have to design an IAM solution .. , I am not able to understand data flow and communication between various components ..
Before answering, the answer will points the asked specific questions, may not fit al your needs. SO is not really intended for writing tutorials or searching the documentation. Implementing an IdP (effecively a security module), one needs to do his homework and learn the details.
Maybe using an ready / out of box solution could be interesting. Using an open source IAM such as KeyCloak, WSO2IS could be a quick start. Or cloud services such as AWS Cognito, IBM AppId, Azure AD, .. could be a feasible solution too
a client using client credentials workflow .. access toked received by our API should be for user logged in
The client credentials grant is intended to authenticate only applications. That's it.
To authenticate users, other grant type is needed. For the user authentication the most common option is the authorization code or the implicit grant. The implicit grant is has its weaknesses and is being replaced by the code grant with PKCE (just search it).
End requirement is users of 3rd-party application not required to login again while 3rd-party application fetches data from our API .. Configuring their IdP (most probably Active directory) and our Auth0 servers for the same is all I need to understand
I see most common two options in use:
1. federated SSO authentication
This is the most commonly used option. The external (3rd party) IdP is configured as a "trusted" federated IdP. You often see the scenario when you have a service provider allowing to login with other IdP, often social networks (FB, Google, ...)
The login flow is as follows:
The client authorizes with the provider's (yours) IdP (let's call it IdP1).
IdP1 now acts as as Service Provider with IdP2 (IdP of the partner) and asks for the authorization (redirects the user to the IdP2).
User is authenticated and authorized with IdP2. If the user is already authenticated, the IdP2 doesn't need to ask the user's credentials again, this is how SSO works on this level
IdP2 returns to IdP1 (acting as a service provider).
IdP1 reads the user information (using the id_token, userinfo service - assuming using the OAuth2/OIDC protocol all the time there are other protocols too) and builds its own the user-level token. It may or may not create a local user (it is called user provisioning).
IdP1 returns to the client and the client can request a user-level token.
Then the client can call the API services with the token trusted by the API provider.
2. Assertion Framework for OAuth Authorization Grants
This option is built on top of the Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants, it is an optional extension of the OAuth2 protocol. I call this a token swap service
Basically the token service could validate the access or ID token of a trusted (partner) IdP and issue its own token based on the provided user information.
As you see there are a lot of information and to build a secure solution you ned to make sure that all steps are properly secured (signature, expiration, issuer, validity, audience, subject domain, .. are validated). Disclaimer - as my job we implement IAM/IDM solutions and a lot can get wrong if shortcuts are taken. So you may really consider using an out of box and proven solution.
I got absolutely confused when trying to understand the differences between MicrosoftAccount, AzureAD and OpenIDConnect authentications.
I am trying to build a .Net Core MVC app that allows some users to authenticate with local accounts, but some with Microsoft accounts. I do need to have a local user in DB for both types of authentications as I have some custom authorization mechanisms built on that.
I started with creating the app from template and selected "local accounts" authentication. Then I added the MicrosoftAccount authentication according to this tutorial (https://learn.microsoft.com/en-us/aspnet/core/security/authentication/social/microsoft-logins?view=aspnetcore-3.1). This is using Microsoft.AspNetCore.Authentication.MicrosoftAccount and seems to be working fine.
However, when I create a new app from template and select "work or school account" authentication I can see it uses a different library - Microsoft.AspNetCore.Authentication.AzureAD.UI. It seems to do the same thing. I can see there are events I could hook into to connect the AAD user with my local DB.
Looking through the web I found some other tutorials that were using OpenIDConnect for the same purpose.
How are those methods different? Which one should I use and why?
In future I would like to be able to query the user's directory for a list of other users. Would that requirement be easier met with either of those three methods?
MicrosoftAccount: This is the login with a general Microsoft account, using OAuth2. This is also what Microsoft will refer to as “private account” and useful when you want to authenticate someone just using their Microsoft login as an external authentication provider. This is similar to how you would sign in to sites with your Google account.
AzureAD: This is the sign in to a specific Azure tenant. This is often understood as a “work or school account” because it doesn’t sign people in using a public account but rather some account bound to some organization. Usually, you would have an Azure tenant where you have direct users (or configure it to allow external users) but you want to control access through that Azure AD.
OpenIdConnect: This is the general OpenID Connect protocol which you can use to sign in with many different authentication providers because it is a protocol that many of them will support. You can use OIDC to sign in to either of the above (and many other services) but that will require you to do some more configuration as you will need to figure out specific addresses for example.
You can always use the OpenIdConnect or the OAuth authentication scheme to authenticate with most authentication providers but those are the “manual” schemes which will require you to configure additional things. All the other authentication schemes, including MicrosoftAccount and AzureAD but also the other ones like Google or Twitter build on top of those protocols and come preconfigured so that you do not need to set up much else. So those are mostly for convenience and for more specialized support.
So when you want to authentication through Microsoft or Azure, then you should choose MicrosoftAccount or AzureAD. Which of those depends on where you want to authenticate with. If you have an Azure AD, then you should use that.
Good evening, I must make an intranet with Liferay, the most important is to integrate a web application (or 2) already ready with the portal that I will make . These web applications are made in php, so in order not to make each authentication, wanted the user to authenticate to the portal and click on the link to one of these web applications, it will not have to authenticate again for its apps. For this reason I used SSO CAS and I integrated it with Liferay, I still used an LDAP directory to be related to the CAS server to identify users.
My problem is how is the procedure for other web apps, is that users must have the same login and password for partail (Liferay) with the others two apps php? Or I can let each application with their users without the change (because in each app, the user has a login and password different from other apps), that is how the coordination between different words and LGIN passes the various apps (this is a problem of SSO, I misunderstood the principle of work I should implement it) ??
Some clarifications and assistance please??
The other webapps need to implement a so called CAS Client. The php one is here:
The php apps will typically redirect non authenticated users to CAS, and after they logged in the webapp retreive a saml token. In that token claims are found that uniquely identify the user. application then typically match the provided claim to their own userstore or apply the concept of a virtual user.
But that is up to the implementer of the webapps.
We are developing a self registration app.
Our app allows users to register for web apps and is deployed on a weblogic 10.3.5 app server. The weblogic is connected to a local ldap system.
Once the user registeres with our app we call corporate servces to generate a user id. password activation, authentication is all handled by the corporate servcies. which also has a corporate ldap that contains all users in the company.
The approach works fine for 'new users' ie users that are not present in the corporate ldap or the local ldap: users enter their details and are issued a user id which we then copy into the local ldap once the user activates their account.
The use case we're grappling with at the moment is how to handle 'existing' users that wish to register. These are users that are currently in the corporate ldap and wish to 'register' with our applications. They get rejected during the normal registration process as they already exist in the coroporate ldap.
What i'd like to do is force them to login (simply so they don't register on behalf of somone else) and once they're logged in simply copy their data into the local ldap.
The problem is even if they are successfully authenticated by the corporate service, they don't (yet exist) as far as the weblogic server is concerned. is there a way to obtain the user id that comes with the authentication token ?
The authentication method is SAML 1.1
The application is a standard Java EE servlet based webapp using the struts2 framework.
Any ideas would be much appreciated.
Within WebLogic, you can define multiple authentication providers and set them up in the order you would like the system to use. Since you are copying data over, you would have to programmatically check for the existence of the account before attempting to create it on the LDAP server.
It would be a lot simpler if you use the external LDAP server directly instead of copying the data to the internal LDAP server, letting you attempt logging the user in and creating the account only while catching the appropriate exception.