I'm currently on a project where there is an existing angular 1.3 app with a couple of API's. These are secured via Azure Active Directory.
The customer has asked for a new tool to be developed that uses these same api's but they want to get rid of the AAD because it's tokens are only valid for 1h and I've been told that refresh tokens and AAD are not working according to those that made the current setup.
I've been reading up a lot on IdentityServer4 and I was hoping to leverage the middleware in order to
a) start using an STS
b) prepare for the future and make the STS a central part to the whole installation.
I've been hoping that I could use IdentityServer4 with a new to be developed Angular4 app with an Asp .NET Core 2.0 WebApi.
The question that I have is: can I do Active Directory based auth (the users are logging in through some citrix alike product) and thus are authenticated because of that. Yet somehow still calling the existing api's with some token that is valid in their context.
And can I use IdentityServer4 to pull this off? Is it a good idea? I'm open for suggestions
Edit
After careful delibiration with the client we've agreed to remove AAD and the token security that currently is in place.
The reasoning:
All installations are done in a DMZ
It's not Azure
The customer isn't willing to change that
This way everything can be secured using Windows Authentication
Time constraints
IS is on the planning for when (5) loosens up
A lot of new tech is going to go in the new client which enforces (5)
Related
I've built a few .NET apps in both .NET core and .NET framework now that use single sign-on (SSO) with Microsoft as an authentication provider, and my company are increasingly rolling this out into older systems too.
The official documentation for adding Microsoft Account external login setup with ASP.NET Core gives the following code snippet:
services.AddAuthentication().AddMicrosoftAccount(microsoftOptions =>
{
microsoftOptions.ClientId = configuration["Authentication:Microsoft:ClientId"];
microsoftOptions.ClientSecret = configuration["Authentication:Microsoft:ClientSecret"];
});
The problem with this is that client secrets can now no longer be set to never expire. I get why this is and that's all fine - the problem this now presents me with is, that at some point the SSO for my .NET APP is just going to stop working without any warning.
Now, yes I could put something in the company calendar or something to go and create a new secret and then go and update all the key stores or settings files with the new keys, but this is really inefficient and asking for trouble. Surely Microsoft can't be expecting us to build stuff with such an obvious point of failure?
Does anyone know how to implement Microsoft SSO without the use of client secrets (maybe a certificate or Managed identity??) so that my apps don't suddenly all break overnight one day?
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.
I have an application built in .NET (C# and ASP.NET). We offer our own register/login login, but a client that just signed up with us requested support for ADFS since that's the authentication service they use across their company. This is brand new to me.
How can I add support for ADFS on my application? I'm guessing my client will provide the new users a link to click that I'll have to process for the SSO?
What would my client need to do on their end? (i.e. add groups and assign our future users to those groups?)
What .NET (or 3rd party) libraries can I use?
Thank you!
You could do this with OpenID Connect OWIN but ADFS 3.0 doesn't support this. So you need WS-Fed (WIF).
The easiest way to do this is with VS.
Create a new ASP.NET project and for "Change Authetication" select the on-premises option.
Use the On-Premises Organizational Authentication Option (ADFS) With ASP.NET in Visual Studio 2013.
Obviously ADFS needs to be configured. You need to find out what attributes the application requires in the form of claims.
Code sample which is similar for Azure AD - Integrating a web app with Azure AD using WS-Federation.
I have begun to work with Microsoft Azure Access Control Services. I would like to create a custom identity provider which would authenticate against our back end CRM system. In the past, I had created a prototype Secure Token Service website which allowed me to do this. However, that was a few years ago. I found
https://blogs.msdn.microsoft.com/mcsuksoldev/2012/11/02/azure-access-control-services-creating-a-custom-identity-provider/
which describes how to create a custom identity provider using WIF to be used within Azure but the site is dated from 2012. I had also looked at IdentityServer3 which I thought may be a replacement for WIF.
Do I use the WIF Secure Token Service approach? Is this obsolete? Is Identity Server the new way to accomplish the same thing?
Thanks.
First of all : Windows azure ACS will probably be discontinued (https://blogs.technet.microsoft.com/ad/2015/02/12/the-future-of-azure-acs-is-azure-active-directory/). We had a contact with Microsoft on this and they said it would be deprecated "two years from now" (not official). This being said, to integrate your custom STS in windows azure ACS is "easy". ACS just needs a pointer to your metadata document. Normally if you have an STS that follows the WS-Federation standards it lives at https://yourSTS/FederationMetadata/2007-06/FederationMetadata.xml. If your meta data is correct, ACS will expose you STS as another identity provider (just like Google, Yahoo etc..). It will do so by offering a "choice screen" that allows an end user to choose the identity provider of her choice. You identity provider will then show up among them. If the end user clicks the link for you identity provider the browser will be redirected to your STS (passive login). If she logs in, a token will be issued to ACS. ACS will them "transform" you security token and issue a new one to the final relying party.
Bon, answer is that you have to expose a meta data document and import it in acs https://yournamespace.accesscontrol.windows.net/v2/mgmt/web/IdentityProvider.
ACS is being discontinued but who knows when.
ACS was originally introduced to provide social logins but has been used for many things e.g. changing token types from SAML 1.1 to SAML 2.0 and vice versa.
The "new" way to integrate social logins in Azure is Azure B2C but that is a completely different type of Azure tenant and has no SaaS integration.
Refer: Azure B2C : Differences with Azure Active Directory (AAD) and Azure B2C : Differences with Access Control Services (ACS).
Identity Server 3 is open source, can do pretty much everything ACS can do plus you can add your own social logins and SAML 2.0 protocol and OpenID Connect / OAuth.
Another good option is Auth0 but that is commercial (and no I don't work for them :-) ).
Regarding WIF, it is still supported but no new features are being added. Rather migrate to OWIN.
Thank you all for your comments and suggestions. Well, a few years ago I had purchased the book - Programming Windows Identity Foundation by Vittorio Bertocci which I used to begin prototyping an SSO solution using the WS-Federation approach which uses a Security Token Service. That project was put on hold and I had not begun to look at this until recently. I purchased Vittorio's new book a few months ago - Modern Authentication with Azure Active Directory for Web Applications. I had only browsed the book but decided to take a it home with me this past weekend and read it thoroughly. The book describes the history of pre-claims authentication techniques to SAML to WS-Federation to OAuth to OpenID Connect. It has a great deal of code examples as well as detailed architectural information. This has cleared up the confusion of the different protocols and I now know in which direction to go.
I have spent quite some time now looking at the Windows Identity Foundation. I even read a few chapters of a book on it on MSDN.
But I'm still confused about one thing. Is WIF appropriate for a public facing web site authentication or is this mainly targeted towards intranets/sharepoint sites, something that deals with internal domain where users are identified by integrated windows auth/active directory or something like that. Currently, we have many web sites for our company where people log in and are authenticated against a data store using forms authentication/custom asp.net membership provider. Is it possible to replace this mechanism with WIF? if so, does anyone have a link to such a tutorial.
I have tried looking for any information along these lines but it has been hard to find.
In principle, there's nothing about Windows Identity Foundation that makes it inappropriate for use on a "public-facing" website and WIF isn't in-itself tied to a particular authentication mechanism either. However, if you were considering using Active Directory Federated Services as your Identity Provider the problem would be that authenticating users against AD would be your only option since that's all it supports (although you can plug in a custom attribute store that retrieves claim values from some other datastore). Your WIF relying-party (i.e. your website) doesn't necessarily care how the user was authenticated, though, only that they were authenticated by an IDP that it trusts.
So your problem might not be that of "WIF-enabling" the websites as such, it may be more a question of finding a compatible IDP that supports authenticating against something other than Active Directory so that you can use the data store you currently use to authenticate users. It is possible to use ADFS as a "bridge" (a Relying-Party Security Token Server) between your WIF relying party and a SAML2 IDP like Shibboleth which can use a database to authenticate users, but configuring such a system is a significant challenge so you'd have to weigh up the benefits that your users might gain from single sign-on to your applications against the considerable effort it would take to set up and maintain such a system.
Yes - WIF appropriate for public facing web site authentication. ADFS v2.0 only authenticates against AD. However, you can write a custom STS that authenticates against anything you like. In your case, with a data store, have a look at Identity Server which authenticates against a SQL DB.
Have a look at:
http://claimsid.codeplex.com/
Identity Training Kit
How to: Build an ASP.NET STS