at the moment I have a single active sts. The sts validates the user with a custom user/password validator. The sts is used for different windows services. Now I'd like to write a asp.net application that uses the sts for login. Later I'd like to change the sts authentication method(e.g. to windows authentication).
What is the best solution for connecting a asp.net site to an active sts. Do I need a passive sts? Do you have an easy example for me?(example code?)
thank you
Yes - you would normally use a passive STS. Refer Get Started with Windows Identity Foundation. There is a ton of stuff in the Identity Training Kit mentioned here.
You could also have a look at Identity Server which is open source and implements the passive profile.
Update:
If you are talking about two different STS, you just federate them.
If you are talking about one STS, they can support both. The only difference is the endpoints for the active and passive connections. "Identity Server" and ADFS both allow this.
If you are talking about "Identity delegation" see Identity Delegation with AD FS 2.0 Step-by-Step Guide. There is an example in the WIF SDK under Samples / End-to-end.
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 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.
We have started looking at this tutorial to use the new notifications hub in Windows Azure:
http://www.windowsazure.com/en-us/manage/services/notification-hubs/notify-users-aspnet/
At one point it specifies a warning stating:
"SECURITY NOTE
The AuthenticationTestHandler class does not provide true authentication. It is used only to mimic basic authentication and return a principle. The user name is required to create Notification Hub registrations. The above implementation is not secure. You must implement a secure authentication mechanism in your production applications and services."
Can anyone suggest a good way to secure this that will work from windows phone, android and iOS. We can't use the built in authentication such as facebook, google, twitter, etc. as it needs to use our own authentication backend.
Many thanks for any help.
To implement cross platform authentication it's best to use a standard like OAuth2.
OAuth2 allows you to
Handle logins in one place on server side.
Your clients only get as few account informations as needed. It's possible to hide the password from clients (whereas not common in mobile apps). Each client gets it's own unique access token.
Remove access remotely by revoking access tokens on server side.
For implementation:
Apache Oltu is a Java Framework for OAuth2 authentication (server and client support).
Udi wrote a very good tutorial for Android authentication.
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