I have a product ecosystem consisting of multiple products i.e: An angular app, a website and a hybrid app all powered by node back end.
So, now I want to add a single authentication and authorization to the whole ecosystem also it needs to be modular and scalable.
Plus I'm following a 3-tier architecture i.e: [APPLICATION] --> [API] --> [DB], only the API layer having access to the DB.
Now I also want the Authentication and Authorization to be another app in the ecosystem that can be plugged into other apps and used without much setup.
Also since It's(Authentication and Authorization module) another application I don't want it to access the DB directly, I want it to make API calls that do it, plus it shouldn't use third party auth schemes like auth0.
Important thing being none of the applications other than the Authentication and Authorization module should have any auth related logic in them.
Basically this should be the module than when plugged in allows Authentication and Authorization and integrates seamlessly.
Is this setup possible? If so how do i go about it? If not how is Authentication and Authorization achieved in other such production grade ecosystems?
Thanks in advance!
Authentication can definitely be thought of as a module; just a widget with a database backend that takes in credentials and spits outs error messages or authorization tokens. Authorization, however, is a bit more complicated; once you have received those authorization tokens, you need to decide what they mean.
Without knowing anything about your applications, I would say that you would need to create a mapping of privileges to user accounts for each application. This is trivial if you just want to restrict users from accessing each other's content, but gets harder if you want to give some users more (or less) power than others. If that is the case, than I'd suggest you use some form of role-based access control. You can find some more discussion on how to handle authorization here.
Related
I have a public-facing application that uses ASP.NET Core Identity to store first-party logins, and no intention of using third-party IdPs like Facebook or Google. I want to build the front-end in React, and the application comprises an API fronting a couple of back-end services to which I'll need to forward JWTs for authorisation.
The plan so far is to use Identity Server 4 as the IdP for the project, backing it into the ASP.NET Core Identity data stores.
Current guidance is to use Authorization Code Flow with PKCE, which would require redirection to the IdP, two sets of styling etc.
In this scenario, where there is no possibility of a third-party IdP, is Resource Owner Password Grant still highly discouraged? On the face of it, it gives a neater experience:
User populates React-based login page
XHR POST to IdP with credentials (modulo an MFA challenge)
IdP returns an access token, React app subsequently uses that for future requests to the API
What issues will I introduce by pursuing the ROPC grant in this specific situation, vs accepting the need and duplication involved in a redirect-based flow to the IdP?
AMOUNT OF WORK
This is one of the big issues. As well as a login screen you'll have to make sure other areas such as Forget Password also work. If you build a second app you'll need to make it work there also.
EXTENSIBILITY
This article summarises problem areas. One of these is no scope to ever extend login solutions.
SECURITY
Token refresh does not (usually) work with ROPG, which leads to long lived access tokens and other complexity. Also, with OAuth it is recommended that the app never sees credentials.
From a security viewpoint it looks more modern to redirect the user - all the big providers do it - eg Google, Microsoft.
BRIDGING SOLUTION
As you say, if the password is private to your app it may not be the worst thing in the world. Capturing a user's Google password in your app would be a bad thing though.
ROPG has its uses but does not have much of a future - it is deprecated in OAuth 2.1 and providers will be getting rid of it. So I would also recommend what LalitaCode suggests ..
You can create a React based Identity Server login page for Authorization Code flow with PKCE instead of using MVC UI if you want. It is just extra work and complicated. I would recommend you just style the Identity Server MVC UI to look exactly like your frontend SPA. This is the simplest way and the path I took when I did a project with Identity Server(with Angular as front end).
Im searching solution about authentication.
I found IdentityServer and Im trying understand how it works.
In my case I need to check user exist in another app.
I have old project created in asp.net web froms and this project have a users collection stored in db.
Now I must create client who will be call to WebApi and in this WebApi I need to authenticate user. I want to do this using IdentityServer4. Can I in IdentityServer call to my old application or db this application and check user by custom method?
In future I want connect another application to IdentityServer and this new application should have users in IdentityServer, so I will be have two places where I will have users for two application. I need to be sure I can check user exist in this two ways.
When request will be form new app IdentityServer should check user in his db and if request is from client who will be call to old app should check this user in external app(db).
Example call:
enter image description here
I dont know I good understand idea of IdentityServer, but generaly I think this is not good solution for my case...For now I understand I can store users in database but only with Asp.Identity in IdentityServer.
What do you think about this case ?
In future I want connect another application to IdentityServer and this new application should have users in IdentityServer, so I will be have two places where I will have users for two application. I need to be sure I can check user exist in this two ways.
When request will be from new app, IdentityServer should check user in his db and if request is from client who will be call to old app, should check this user in external app(db).
The short answer is that IdentityServer4 is just an implementation of the OpenID Connect protocol and the persistence and authentication of users is entirely customisable so you're free to implement that any way you like.
As for where to keep your users - that will depend on your problem domain and business rules but I'd probably try and avoid using multiple DBs if possible and instead migrate existing users from legacy applications to your identity service's own store and take care to only bring over identity and authentication information and not access control/authorization information. i.e. keep the authorization logic in your client applications and APIs.
One of our clients requested that we integrate our system with ADFS (Active Directory Federation Services) while another requested that we integrate with Okta. They want the experience to go something like this: the end users opens up the Windows app (on their domain joined computer) and is able to use it right away with implicit authentication from one of those identity providers. No extra clicking or registration. I am willing to create multiple copies of the application integrated into these different identity providers if necessary.
Our current setup uses Node/Express as a backend (hosted on amazon web services) and all traffic is sent through this API. Our client interface is a wpf Windows application. This seems to be a less common setup. Currently, the user must sign up with an email and password, and must log in using that same email and password to start using the application.
There are 3 parts to this question that I'm super confused about (I'm an intern with limited knowledge, so please explain like I'm 5 if possible). On the other hand, I believe I have a solid understanding of how Single Sign On conceptually works (with us being the service provider and ADFS/Okta being the identity provider). Even if you can answer parts of these questions, I would be super grateful!
What (if anything) do I have to do to our API backend? I'm assuming everything just needs to be done through the windows client right? But then I saw a passport saml package but I'm unsure if I need it to complete this task.
What do I have to do to our frontend? I've tried one of auth0's sample windows application but it seems like everything is still going through a login screen. At least for any social media connection. We'd like to ideally do this without a login screen and hopefully without proprietary software like Auth0 (since we manage our own user database already). We just want something so that at startup of our wpf application, the application queries for user's information (through ADFS or Okta) and then all behind the scenes, the user is logged in automatically. Any pointers here?
What I do have to do on the 'main' active directory Windows server side (this would be on a client's enterprise network)? I've seen hints of setting up callback urls, certificates, metadata, and something, but I'm unsure of what all of that is. Lots of questions just reference that but don't explain what or why it's needed?
Lastly, I apologize if any of the questions are vague, I have tried to do research, but it just seems like all the pieces are either too advanced or just don't apply to my setup. Thank you for your time!
ADFS etc. rely on federation protocols like WS-Fed and SAML 2.0 and so the IDP behavior is determined by the protocol.
There is no browser based functionality to just log you in.
You will always be taken to an IDP login screen. Once you have authenticated, other applications on the same IDP won't require authentication. They can seamlessly log you in based on cookies.
You can't query for user info. until you know who the user is.
On the ADFS side, you can manually configure a RP (your app).
I'm trying to implement IdentityServer3 into my architectural mix. I like the idea of registering Clients, Users, and Scopes. What I do not like is using IdentityServer3's built in login and registration forms.
I have 4 different apps that need to use my IdentityServer3 implementation (aka TokenServer). These 4 apps are AngularJs apps. I have various C# .Net WebAPI services supplying data to these 4 apps. Right now each of these 4 apps have their own authentication and registration process. I need to consolidate authentication piece using IdentityServer3.
Each of these 4 apps have different account registration/authentication needs. There's a mix bag of 3rd party authentication (Facebook, Google) as well as traditional forms authentication against an account the user has registered with.
So, I cannot have any of my AngularJs apps use the default Login/Registration forms that come with IdentityServer3. I've spent a lot of time now trying to find a way to turn off the default views and just wire each of my AngularJs apps to my TokenServer. I simply want to POST login credentials to the /token endpoint and return a token that can be used in subsequent calls to my WebAPI. I want to replace the authentication process I have for each app with IdentityServer3 without changing the existing login/registration UIs.
I cannot find a sample app or even documentation that shows how to do this. Is it even possible to 'turn off' every one of IdentityServer3's UI views and use my AngularJs client's login and registration forms?
Please point me in the right direction. Thanks for your time.
It seems you want to use the OAuth 2.0 resource owner flow - which means - your app posts credentials to the token endpoint and gets back an access token. That is totally possible - you will miss out on some features like federation and SSO. But these are the known constraints of this flow.
If you want to use a redirect based flow (which gives you SSO and e.g. Google logins etc) - you need to redirect. You can replace any of the IdentityServer views with your own. The documentation and samples have plenty of information how to do that.
https://identityserver.github.io/Documentation/docsv2/advanced/customizingViews.html
https://github.com/IdentityServer/IdentityServer3.Samples/tree/master/source/CustomViewService
I have been trying to determine a good strategy for authentication between a single WPF application of which calls to Web API services.
The client WPF app should be the only application to ever call the Web API.
I think I do have some unique requirements I must abide by. For example, The boss does not want to use ssl in any way; he is paranoid of users may having to deal with certificates.
Like I said, the client application is the only client using the Web API. The API just calls a list of stored procedures on a separate server.
Currently, we have a user membership database that does not align with any membership db standard, but we currently have over 200,000 members. One of the stored procedures currently authenticates the user with the membership db. The client application requires valid users to sign in to the application at start-up, however, we are wanting to secure all of the Web API requests sent from client to prevent non-valid requests being made to the server and so to prevent.
We are concerned about using the individual accounts or local authentication to essentially authenticate every web API request because of the added cost.
I have been thinking that what we are really needed to do is pretty much authenticate that it is our software client(WPF application) making the request and this authentication could open up all the controllers and actions for requests made by the client rather than the user. The user and its authentication is somewhat separate and is in place to prevent unauthorized users on a particular machines install of the application.
So you must have a valid user account to use the application.
Any suggestion would be great. I am just asking to get pointed in the right direction. I am really new to security so all suggestion will be valuable to me.
Thanks.