Simple situation. An existing project will need authentication and authorization and I need to design it. First of all, I choose to divide the whole thing into two modules, one for authentication and the other for authorization. Both will be seen as blackboxes for the project. For now, the authentication module will just use the Windows account of the user, link this to an unique GUID and offer this GUID to other modules as the user ID. Newer versions of this module will do more "magic" but for now, this will be enough.
The authorization module will be a bit more complex. It will use the GUID and link it to the access rights of the user. With the GUID, it could communicate with the authentication module and request more user information.
But next to roles, should the authorization module also manage some other user data, or would it be better to add them to the authentication module? (Think about name, address, phone, office name, gender and how they like their coffee...)
Basically, the authentication module will contain an interface and customers who like to use our software can use out default authentication module or use the interface to develop their own version. So I don't want it to keep too much information.
And would I need more information in the authentication module than just the roles?
If the applications using the authentication benefit from shared information, such as change in email address, it could be stored in the authentication system. In fact, the authentication call can be implemented as retrieval of the user information along with some credential such as password.
Authorization (roles, access rights, etc.) on the other hand could be more specific to the individual application and its capabilities.
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 was wondering if it was possible to login to different salesforce environments (Sandboxes, scratch orgs, production env, etc) using either Apex/LWC/Aura (or anything that I can make a quick action to). For example, I have a list of credential records, with the username and password, and I would like to have a login button that creates a separate tab that can automatically redirect to that specific instance and log in.
Currently, if a user wants to login to a particular instance, they have to either go to test.salesforce.com or login.salesforce.com (depending on if it's a sandbox or production) manually, then copy the password and username in. The ideal situation is to have a login button that can do this automatically from the record page where the username and password is located.
I think previously this could have been accomplished through the URL, but salesforce has recently patched this out due to security concerns. Is there another good way to do this?
It sounds like you're trying to solve two specific challenges:
Your users need to be able to manage very high volume of credentials.
You need authentication to survive password resets.
The clear solution, in my mind, is to use the OAuth Web Server flow to execute initial authentication and then store the refresh token that results from this flow. This token survives password resets, and may be used more or less indefinitely to create new access tokens - which users can then use to log in via a frontdoor link.
There's an out-of-the-box tool that does this already: the Salesforce CLI. You can authenticate orgs to its toolchain, name them, and subsequently access them with a single command (sfdx force:org:open). Users that prefer a GUI can access the exact same functions in Visual Studio Code.
If you're hellbent on doing custom development to handle this use case, you can, but you need to be very careful of the security implications. As one example, you could implement an LWC + Apex solution that executed the relevant OAuth flows against orgs and stored the resulting data in an sObject, then allowing users to click a button to generate a new access token and do a one-click login.
But... if you do this, you're storing highly sensitive credentials in an sObject, which can be accessed by your system administrators and potentially other users who have relevant permissions. That data could be exfiltrated from your Salesforce instance by an attacker and misused. There's all kinds of risks involved in storing that kind of credential, especially if any of them unlock orgs that contain PII or customer data.
One of the two best answers for that (the other one being 'pure Apex' and relatively more complex) is using Flow.
"You can use a login flow to customize the login experience and integrate business processes with Salesforce authentication. Common use cases include collecting and updating user data at login, configuring multi-factor authentication, or integrating third-party strong authentication methods.enter image description here"
"You can use login flows to interact with external third-party authentication providers by using an API.
For example, Yubico offers strong authentication using a physical security key called a YubiKey. Yubico also provides an example Apex library and login flow on GitHub. The library supplies Apex classes for validating YubiKey one-time passwords (OTPs). The classes allow Salesforce users to use a YubiKey as a second authentication factor at login. For more information, see yubikey-salesforce-client.
You can also implement a third-party SMS or voice delivery service, like Twilio or TeleSign, to implement an SMS-based multi-factor authentication and identity verification flow. For more information, see Deploy Third-Party SMS-Based Multi-Factor Authentication."
learn more here: enter link description here
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
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.
We have a client with following existing product line
Website1 (Uses form authentication using user information stored in SqlDB for website1)
WebSite2 (Uses form authentication using user information stored in SqlDB for website2)
WinApplication1 (uses Active Directory to authenticate user)
More products in line for future release.
They want to implement Single Sign on (SSO) for all their products with following features-
Product list that will be accessing by a user will be depended on his/her role.
It should be configurable. Roles are being defined in DB having Fk relation
with user table.
SSO service should be flexible to accommodate new product.
should use SAML to sucure token.
WinApplication1 has link for website1 and website2. If an user is login in WinApplication1
and click on any links of website1/website2, user should able to access the sites without
entering his credential.
If user is logned in in any product that user should be all to access any other product
he has access right without enterting userid/password.
We have following query
We are planning to implement SSO using WCF and WIF. Can all above requirement be fulfill
by using WIF.
We want to keep user authentication part in respective product as each product has their
own user store. OR WE SHOULD HAVE CENTRALIZED USER STORE?
What shouldl be the responsibility of STS (implemented in WCF) in respect to SSO &
security?
We have read lot about WIF from MSDN(http://msdn.microsoft.com/en-us/library/hh377151(VS.110).aspx, http://msdn.microsoft.com/en-us/security/aa570351.aspx) could not find any solid article/sample giving some practical scenarios. Most of them about using local STS…may be it is my bad luck.
I found a article that matches most of your requirements with practical implementation example.
The article describes an easy approach for programming against Windows Identity Foundation in a Single Sign-On (SS0) scenario from the angle of a relying party application. WIF supports a variety of Claims-based authentication scenarios but this document will focus upon using WIF to develop an application that supports SSO given the use of a SAML 2.0 token containing some basic claims.
Article also includes some part explaining about using roles in AD Users:
http://www.c-sharpcorner.com/UploadFile/scottlysle/windows-identity-foundation-and-single-sign-on-sso/
To impersonate the Original Caller in WCF Calling from a Web Application, you additionally need to follow:
http://msdn.microsoft.com/en-us/library/ff650591.aspx
Update:
difference between IP-STS and FP-STS and how to choose where to put STSes in your architecture. You will learn about federation, home realm discovery and how to leverage the WIF extensibility model in order to handle multiple identity providers.
http://bit.ly/bTo3w4
How a generic web site can be enhanced with identity provider capabilities regardless of the authentication technology it uses, simply by adding an STS page.
Another lab shows how to use an existing membership store for authenticating calls to a custom STS and sourcing claim values.
http://bit.ly/bQAQhA
WIF and WCF
http://bit.ly/8X63T5
Hope it helps.