I currently have a solution with three projects
Identity Server 3 with web host
MVC Application with UseOpenIdConnectAuthentication
Asp.Net Web Form Application with UseOpenIdConnectAuthentication
Both the Mvc and WebForm are pointing to the same Identity Server and both are configured to use the same client. The Client is setup as a Hybrid flow and has both the MVC and Web Form urls registered against the client.
Both can authentication with the same user account details and the claims identity is working fine within the applications. Both are setup using the OpenID Connect Authentication with the same
Client ID
Authority URL
Response Type
Scopes
SigninAsAuthenicationType (Cookies)
Both the Mvc and Web Form are set up as UseCookieAuthenicationType (Cookies).
However when I transfer via a hyperlink from the WebForm application to the MVC application, it does not recognise that I am already logged in.
Can anyone tell me what I have configured wrong?
Can you please provide some code snippets from clients UseCookieAuthenicationType/UseOpenIdConnectAuthentication -configurations? Is Authority -property setted with valid endpoint? With security cookie it is case sensitive - this is important
Related
Im trying to implement IdentityServer authorization and my scenario is below:
we have one home page for all our application "www.vision2025.com" and i have link to my mvc application "MarketingDashboard" where users are authenticated by home page and redirect to my mvc application using windows authentication. Now user can do any action in my dashboard which interact to web API.
Now i need to implemented IdentityServer to authorize all the web API call from my dashboard but no need of login.
Please suggest any idea
Thanks in Advance
I think you don't want to build IdentityServer because your enterprise company has already built ADFS (Active Directory Federation Services). You just want to ask who maintain AD and ask him to enable ADFS for OAuth2. This is a page to help you catch all scenarios here.
Because I don't know how far you can change for all applications but there are some solutions with ADFS you can go with:
Let your main server (acts as Home Page and where user redirects to ADFS to sign in) performs On-behalf-Of flow. In this scenario, your main server will be a linked server that transfer its taken access token which retrieved from ADFS. I strongly recommend this way because you just want to add as many as your new upcoming web and api. The cons are they require you ensure protect highly access token in your main server
Because OAuth 2.0 doesn't support chaining Resource Servers yet (such as you signed in Resource Server A, then use provided access_token to call Resource Server B in different clients), you need to allow your main server store his username/password (also knew as trusted back end server , means your enterprise allows this server can store client credentials). So each time you redirect user to target MVC Application, you should transfer encrypted username/password as well. Then your target MVC application can perform Authorized Flow or Implicit flow itself in Back-end code, then returned new access token to client web to perform calling Web API.
I have created a Web API using ASP.NET Core 2.1 and it uses (successfully) JWT as a method of authorising requests.
The API is linked to a SQL Server database.
My users are stored in it using Identity as the base framework.
To authorise access for my API I take the username and password which is checked against the stored (Identity based) user.
Successful login returns an Access Token (with a 30min life).
Upon first logging in, a Refresh Token is generated and stored against the Identity user and sent back from the API.
All of this works well. My next step was to create a separate .NET Core 2.1 MVC site which consumes the API.
My question is:
From the MVC site point of view, how do I secure my controllers and views based on this security set up? I would normally use the [Authorize] attribute as part of Identity.
All I have on the MVC site side at the moment is the Access Token (and Refresh token) for the user in question.
I'm thinking the following solution:
MVC Site has it's own database and authentication for users (using Identity).
The connection (credentials/tokens) to the API is stored separately in the MVC site database and used as a 'global' way on the server-side to execute calls against the API
You should use an OpenID Connect and OAuth 2.0 framework. please check IdentityServer4. It also support asp.net core identity
IdentityServer is an OpenID Connect provider - it implements the
OpenID Connect and OAuth 2.0 protocols.
Different literature uses different terms for the same role - you
probably also find security token service, identity provider,
authorization server, IP-STS and more.
But they are in a nutshell all the same: a piece of software that
issues security tokens to clients.
IdentityServer has a number of jobs and features - including:
protect your resources
authenticate users using a local account store or via an external identity provider
provide session management and single sign-on
manage and authenticate clients
issue identity and access tokens to clients
validate tokens
How do I integrate an existing asp.net MVC application with a separate IdentityServer application?
I have an existing asp.net MVC site using identity 2.0 for authentication.
I now have a second application running asp.net Core 1.1 which serves API's which talk to a client (mobile) application.
I need to share authentication across all 3 applications.
From what I've read, I need to add SSO, and IdentityServer seems like a great solution for this. I plan to set up IdentityServer as a 4th application and connect it to the new .net API application and client application.
But I can't find any example for how to have my existing Asp.net application use the new identity server for authentication.
You will have 4 applications are you stated.
The IdentityServer4 application for identity and access control. This will be the SSO service and the STS (security token service)- the authority. As of today you will build this in ASP.NET core 1.1. To be an SSO you will of course need to have a user database; using ASP.NET Identity works well and integrates nicely with IdentityServer.
Your Web API, which you say is running ASP.NET Core 1.1. This, in OAuth terms, is called an API Resource. You could sub divide this API into separately securable sections called API Scopes.
The existing MVC web application with your current user database in ASP.NET Identity. This will be a Client of the IdentityServer authority (#1 above). You could use the Authorization Code Flow (more secure) or opt for Implicit or Hybrid flow. An example of how to setup an ASP.NET MVC web application as a Client of an IdentityServer instance can be found in their official documentation: http://docs.identityserver.io/en/latest/quickstarts/3_interactive_login.html#creating-an-mvc-client.
Essentially, you
(a) register the client with IdentityServer, then
(b) add some startup code in the client app that will tell it to use IdentityServer for authentication- something like this...
app.UseOpenIdConnectAuthentication(new OpenIdConnectOptions
{
AuthenticationScheme = "oidc",
SignInScheme = "Cookies",
Authority = "http://localhost:5000",
RequireHttpsMetadata = false,
ClientId = "mvc",
SaveTokens = true
});
You could at that point use both the internal user database for logging in as well as the external IdentityServer- that is, you could log in to the MVC web app two different ways. The IdentityServer app could be considered an "external provider" to your MVC web app.
Are you going to migrate your existing usernames and passwords (and roles, etc.) to the new IdentityServer instance/database? This answer will have to be "yes" to achieve SSO and shared identities and access controls across applications.
SSO is only possible if the user logs in with the IdentityServer app. Though, you probably won't actually achieve SSO since they are using a browser on a desktop machine and a mobile app on a phone- not really able to share cookies or tokens across devices.
The mobile client. This would be another Client like the MVC web app except using the Implicit Flow for sure. Again, register the client, and then code the app.
You build your Authentication application by using IdentityServer4. Treat each of your application as an identityServer4 client and API as ApiResources, so they all will have unique clientid, callback uri etc. You need to add IdentityServerAuthenticationOptions to API, and OpenIdConnectOptions to mvc application.
For example, an WebAPI startup.cs may have:
public void Configure(IApplicationBuilder app, ILoggerFactory loggerFactory)
{
loggerFactory.AddConsole(Configuration.GetSection("Logging"));
loggerFactory.AddDebug();
app.UseIdentityServerAuthentication(new IdentityServerAuthenticationOptions
{
Authority = "http://localhost:5000",
RequireHttpsMetadata = false,
ApiName = "api1"
});
app.UseMvc();
}
Anyway, First you need to understand how IdentityServer works. And then you need to build the identityserver app what will access to your users context. You will achieve share authentication across three app by allowing same api scope.
And this is the best place to start
I am developing an asp.net MVC web application that will be deployed in the cloud and should support the following authentication scenarios:
Transparent authentication for domain users on an intranet. These users should be able to access the application without signing in.
Forms login for arbitrary non-domain users on the internet. These users should be presented with a login page using Forms authentication, and membership is managed internally by the application.
Forms login for domain users on the public internet. They should be able to use the same login form as non-domain users, but sign in with their domain credentials instead.
Active Directory Federation Services (ADFS) with passive authentication can cover cases #1 and #3. Since it redirects to the federation provider's login page, it doesn't cover the #2 case. I understand active authentication by my application could possibly support all three cases, however there is not much documentation around on how this would be implemented.
Ideally there should be a way for my application to authenticate a domain username and password with the ADFS federation provider.
Does anyone know whether this is possible, and if so, how?
The standard pattern for this is ADFS with a split DNS - IWA for intranet and Forms for internet.
However, ADFS can ONLY authenticate against AD so option 2 can't be achieved.
I would suggest using IdentityServer for option 2 - you may have to customise it depending on your "flavour" of membership - and then federate ADFS and IdentityServer.
IdentityServer is free / open source.
To expand on nzpcmad's answer, you can set up Claims Provider trusts other than Active Directory in the ADFS Management console under Trust Relationships > Claims Provider Trusts, they effectively chain ADFS with custom STS services.
The entries you add will be added to the Home Realm discovery page within the ADFS web site, such that authenticating users will be presented with a drop-down list to essentially choose the Claims Provider they wish to be authenticated against.
Automatic sign-in will still work for internal users who choose your Active Directory (ADFS provider), whilst members of other Providers will be redirected to their chosen Claims Provider's web site, which will typically present a Forms login page and authenticate against a back-end membership database, all external users (who are not able to present an NTLM or Kerberos token will be required to enter their details - for AD users this will mean they have to enter their domain\user string (or user#domain) and internal password.
Of course, you have to create these providers yourself, in the old WIF days this meant using the fairly clunky Custom STS template, however you can now streamline the procedure with a simple OWIN-based MVC5 site. Alternatively, as nzpcmad suggests, you could look at using IdentityServer.
We have two existing legacy web applications, one for the intranet using windows authentication within the domain, and one internet application, performing a custom web forms username + password based authentication. Now a new web applications is developed and will be available in the internet to both internet and intranet users, handling both authentication models. Therefore we decided to use WIF. We're going for ASP.NET 4.5 MVC 4 on Windows Server 2012.
The intranet authentication shouldn't be a problem as we can use ADFS 2.0 here.
But we currently have no clue how to solve the username + password authentication. It looks like we need to develop a custom UserNameSecurityTokenHandler to authenticate users which provide username + password information which is verified against our custom membership provider. But I need some assistance with the whole workflow...
Assume that we have a custom login page for internet users; and assume that we managed to route internet users to this login page (in ASP.NET MVC), what's the missing part from here to a valid token? How would the form or the MVC controller action which received the provided username + password proceed to trigger the configured WIF identity provider?
The most elegant solution would be to create another STS for the external users and have ADFS trust this as an identity provider:
External users will be redirected to the IdP STS that would use the usr/pwd database. Internal users will authenticate through ADFS directly (against AD).
In this scenario, ADFS is acting both as an IdP and a Federation Provider.
For this to work you need both ADFS and the IdP (and the app) exposed to the internet. An STS you can use that leverages membership is IdentityServer, which is open source and you can of course customize for your needs.
With this architecture you don't need any special customizations/extensions in the app. You will need to handle "home realm discovery" though. Which is the process of knowing where to authenticate users on (e.g. intranet vs. extranet). Presumably, you might have different URLs, etc.