I have two solutions under the same domain. The first one is MVC application with authentication based on IS4 OpenID Connect provider, I'm using code flow. The second one is Angular SPA application with backend on ASP .NET Core ( server just serves static files), authentication here also should be covered by IS4. My question is how can I share authentication state of MVC app with SPA app and vice-versa. Also I can add that it's not necessary to have two separated clients. Authentication can be shared under one client for both applications. Thanks.
Example:
mysite.com/page1 - MVC-client,
mysite.com/page2 - SPA-client
Authentication state will be separate since they use two incompatible technologies:
Client side SPA uses tokens to call APIs
Server side web app uses auth cookies to call a back end
What is common though is the SSO session cookie with Identity server, so after signing on to App 1 you can Single Sign On to App 2 - without a second login for the end user.
This is how separate OAuth apps are meant to behave - the separate redirects mean they can get access tokens with different levels of access to APIs.
This is the simplest solution and any other option could require a lot of re-engineering and has the potential to become a little hacky.
Related
I'm working on building a series of micro-services using Aspnet Core. A mobile application, desktop application and web-application will consume the services over Http REST APIs.
For user auth, I'm utilizing the Aspnet Core Identity platform, but I'm exposing the creation of user accounts via a REST API. The clients make a REST call with the credential information and my API uses the Microsoft Identity APIs to provision the user. The user would be authorized to hit the individual resource servers with an auth server using IdentityServer4.
I have two questions that I've not been able to find clear guidance on from a security stand-point. Should the Aspnet Core project that utilizes Microsoft Identity for user creation be in an independent Aspnet Core project from the project that handles auth via IdentityServer4? Are there downsides do separating the two out that I need to consider?
The Microsoft Identity API has template and Razor Views that can be used to handle the auth from a server-side perspective, including redirects on account creation or sign-in etc. If I'm doing everything via SPA or Client-side native apps, is there anything wrong with just providing a POST API that accepts the user information, creates the account via UserManager<T> and returns the UserId?
I want to provide a dedicated sign-in page, similar to FB/Google/Twitter etc for Auth to happen across any app that wants to authorize a user for my services. I don't typically see account creation as part of the OAuth process though. Is it typical that you would allow for redirects to an account creation page, that redirects back to a client upon successful account creation or is that process typically just used for Auth via OAuth flows?
I would suggest to consider using one service for IDS4 and ASP.NET Identity since they can be integrated and give you the full functionality you're looking for(auth, and users management).
IDS4 has examples and good documentations regarding that.
To me, I think separating them would be an over engineering.
one example: when IDS4 generate access token for a user, you should get claims, roles and validate username and password, all of that are stored in ASP.NET Identity.
So for more details you can check the docs of Identity Server 4: http://docs.identityserver.io/en/latest/quickstarts/0_overview.html
or it's my pleasure to check my little blog post that I tried to give some more detailed and step by step.
https://feras.blog/how-to-use-asp-net-identity-and-identityserver4-in-your-solution/
Start with IDS4 link because it might be enough :)
The main point when thinking about security management UI is how to secure that UI. And the most safe approach for today is cookie-based auth with same-site cookie (the way, MVC uses by default). Consider that when and if selecting serverless SPA pattern. For management purposes-app having strict backend is much more secure than token-based access to distributed api-s.
Regarding the application hosting, #VidmantasBlazevicius is absolutely right, there is no the only strategy: hosting all the services in one app is simpler, so it better fit lo to middle loaded systems. But with raise of the number of users and authentication requests, you might want to scale, and separating management UI from authentication is one of the ways to handle that.
We have a webforms (.net 4.5) application which uses membership for user authentication which we host ourselves. Our clients have Active Directory and ADFS which they host in their own networks, they require our software to use single sign on authenticating against their ADFS server. I'm looking for steps on how to implement this so we can continue to use our normal membership login but use SSO where available.
There's a lot of info out there and I honestly don't know where to start. Cheers.
I wrote up something very similar to this:
OWIN : ASP.NET MVC application with multiple authentication options
Basically, use the OWIN Identity stacks to support whatever protocols you want.
Note that this application (RP in ADFS speak) still needs to be configured on the ADFS side.
I am investigating how IdentityServer 3 works and I still have problem to fully understand.
In general concept is clear to me but still I am not sure how to implement this on real project.
This is basic example that I am trying to implement in my case: link
I have web api project and I want to call my api methods from any client (mvc, wpf, phone…)
So I need implementation that is suitable for all clients.
If I understand well (and probably I am not understand completely), I should have 3 projects:
Client
Api
Project that host IdentityServer
And all projects should have required stuff like on picture:
Steps on picture:
Get token
Return token
Call api
Check if Token is OK
If Token is fine than return data else show error
My questions are:
Is my thinking about how this works ok?
Where I making mistakes?
Is this example good enough for my case? Am I missing something
important?
Do I have to create project that host IdentityServer, or this is
needed just for example code ?
Does IdentityServer host project must be console application that
communicate with api and client(like in example), or in real world
this is done differently ?
Should project that host identity server be aware of Clients and
Users ?
Should some other project except host identity server project be aware of Clients and Users ?
What is diference between implicit and hybrid flow, what I need in my case and why?
How do I create my own login view? I want have html page for login if I use web client, but to have wpf login view if I use wpf, also different view for mobile client.
EDIT:
I think that I need Resource Owner flow . I supose that resource i view where user type user name and password.
Your basic flow is correct, with Identity Server acting as your authorization server and your client and web API separate.
You should host Identity Server in its own project to ensure it is separate from any other logic which has the potential to introduce security concerns. How you host it is up to you and your use case. Typically you would see it hosted within an ASP.NET project on an IIS Server.
Identity Server must be aware of clients and users in order to authenticate them. The only other projects that should be aware of your identity store (users) is any applications that concern things like admin, user registration, etc. The client store would only ever be used by Identity Server.
Views can be modified using the Identity Server templates or by introducing your own ViewService. See the docs for more info: https://identityserver.github.io/Documentation/docsv2/advanced/customizingViews.html
Regarding flows, the Resource Owner flow is OAuth only, so there will be no authentication (log in page), only authorization (server to server).
We are building a web application that also includes webAPI's. These WebAPIs needs to be exposed to other applications as well (other internal application on different subDomain or 3rd party application). We are thinking of using OpenId Connect, so that not only we will be able to give access_token but also id_token for authentication.
Now the question is 'Should my main application also use openId connect' for authentication/authorization. I am not in favor of this. As per my understanding, only external applications should use openid connect to use main application's resources. And internal applications (main as well as application on different sub-domain) can work with regular cookie based authentication.
For instance, main application is MyWebApp.com (this includes webapi as well). Other internal applications are maps.MyWebApp.com, admin.MyWebApp.com, payroll.MyWebApp.com.
Other 3rd party application could be OtherWebApp.com.
Please suggest.
"Should my main application also use openid connect?"
Advantages
- paves the way for single sign on
- modularizes your authentication so you're not implementing different authentication solutions.
- you have the option of using the same Web api from your main app. (although you could just use the oauth2 client credentials flow and simply skip the openid connect authentication part)
Disadvantages
- if you only had one client app then this could be overkill
- you're adding complexity to the app by making it depend on an authentication server app (but modularizing has advantages too)
I don't know your scenario completely but I'm inclined to say yes. Although, I'd definitely turn off the consent screen from oauth2 for your trusted main app. If you don't use openid connect for authentication, it shouldn't be too hard to convert your main app to use it later
i am developing an applications which uses ASP.Net MVC 4 (.Net 4.5) and self-hosted websockets. For the user-handling and login-process i use the default asp.net mvc formauthentication system.
Does any one have an idea, how to share the login-session between the IIS (ASP.Net MVC) and the Windows service?
Thank you!
If you have several applications that all require same user to be logged in, then you need to implement a security pattern called Single Sign-On (SSO).
This requires that you have a centralized place where your authentication is done, and that place is called Security Token Service (STS) or Identity Provider (IdP).
When user attempts to access either your MVC application or your websocket endpoints, your authentication logic in application must redirect him to STS. STS will then require credentials, and based on those it will issue a Security Token. Client will then return to application that has caused a redirect and carry token with it. That token can then be used on any other application in your realm and as long as it is valid (not expired), security session is valid/shared on all your applications.
I'd suggest that you read about Windows Identity Foundation (WIF) 4.5 and SSO patterns, as some of the things mentioned above come out-of-the-box with WIF.