I'd like to setup an integration with a third party vendor for which I have to provide services, which need to be customer-aware.
The main flow is on the third party, that already have a service provider and an identity provider; the third party service provider then have to call my service, but then I need to check the authentication, for which I would like to rely on their identity provider, gaining so also access to the user identity (name, mail, other data).
basic flow
Does a flow like this can work? Do I have to receive the authentication infos cookie? Are other ways for which I can integrate with the third party identity provider?
Current web standards would likely dictate OIDC, especially if you want your service to be open to direct consumers as opposed to, or in addition to enterprise users. Were I building something today, I would choose to build out only OIDC, because it doesn't limit the Identity Providers I may want to use. In addition to enterprise, you could consider social logins as well, such as Facebook, Google, etc. If your users are ONLY enterprise users, then yes, you could consider SAML.
The identity data is usually returned to you in a JSON Web Token, or JWT.
I would suggest looking at OIDC implementations on your favorite stack, or look to a cloud provider.
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.
The question: Should I use .Net Core Identity or IdentityServer 4 with Identity
I need to build app with login/register functionality and allow users to use APIs to import/export data from my software. I also want to have external logins like google, twitter, etc.
And I'm not able to understand why would I need Identity Server when all things can be done using only Identity.
Why would I need or want IdentityServer ? I just need to get work done right and as simple as possible.
You really can't compare the two.
ASP.NET Identity is a database API to manage users, roles, claims, email confirmation tokens etc. Something you can use for implementing signup, login, change password etc.
IdentityServer is an OpenID Connect and OAuth 2.0 implementation. It gives you features like single sign-on and API access control. This is useful if you want to share users between multiple client applications.
You can combine both though - use IdentityServer for the protocol work, and ASP.NET Identity for the user management on your central login page.
It depends.
IdentityServer will provide you with OAuth 2.0 and OpenID Connect implementation, and it will handle all details for you (providing you endpoints, token management, scopes, grants and so on). It runs independently so you can use it for multiple clients (SPA, mobile, web apps) and it is nicely isolated from rest of your app. If you wish so, you can use it together with ASP.NET Core Identity.
If you don't use IdentityServer, you will have to write some of these things yourself because ASP.NET Core Identity is a membership system and it does not provide any ready to use endpoints and neither token management or support for different ways how to authorize.
You need to evaluate whether it is better for you to write these things yourself but have a more straightforward setup because you probably don't need everything IdentityServer provides although it might limit you in future.
You can also have a look at OpenIddict that is less complicated than IdentityServer.
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.
My company is planning to host some applications on public cloud. For identity management in cloud, my understanding is that we have 3 options
Federation
Provisioning
Identity as a service
My understanding for federation is that any access to cloud based services, can be intercepted and pointed to identity provider within the organization, which will then perform authentication and authorization, provide a token and the application can inspect token and allow/disallow access
For provisioning, instead of identity provider being located within organization, it can be located in cloud and it can refer to identity stores in cloud, which are provisioned in batch or real time by standards such as SPML or SCIM
Is the above understanding correct?
An app being deployed to the cloud has little to do with identity federation or identity as a service. You could very well use Forms authentication on a cloud service.
The question is whether you want to make your app responsible for authenticating users or not. If you choose not to (which is likely a good thing), then you need to rely on a mechanism to outsource identity. The techniques to do this are referred to as "claims based identity", "identity federation", among others, and involve a number of protocols (e.g. SAML, SAML-P, WS-Federation, OAuth). These depend on the systems you want to use for authenticating users:
SAML/WS-Fed are typically used for enterprises (using AD for example)
OAuth is mostly used by consumer oriented systems (e.g. Facebook, etc).
So, depending on where your users are you might need to implement one or the other (or both).
Identity As a Service, means you use an external service provider to handle authentication with these providers for you. It is not a requirement and you could build this capability on your own.
Without details of your infrastructure and your app it is difficult to provide any guidance: ASP.NET? Java? nodejs?Azure? AWS? Heroku? Where are your users?
We are working in an iOS application and we use back-end in azure. We have 2 types of login, one is Facebook login (using Fb as identity provider) and the other will be login directly to our system.
We decided to use ACS but we had a bunch of technical problems. My question is is it possible to create custom identity provider, which will be a service (for example WCF or WEB API) to generate a token that we pass the ACS to get the claim token. Does ACS support that kind of service interface? If so what what is the practice of generating tokens in our custom identity provider?
Thanks in advance,
Deuce
ACS can support any identity provider that speaks a protocol it understands. Depending on the backend behind your identity provider, you can use something like ADFS or write your own identity provider using WIF. ACS doesn't support mixing and matching web-based identity providers with WCF-based ones, which means that you'll need to expose a website that ACS can redirect a browser to using the WS-Federation protocol. The only external contract you have is that ACS will redirect users to you and you need to log them in (what that means for your IdP is up to you) and issue a token back to ACS.
There are literally whole books on how to write your own STS using WIF, to get started there are a number of resources that can help, including the WIF SDK (which provides a template for the STS), this whitepaper (see the section "Using Windows Identity Foundation to Build a Security Token Service"), or this blog post.