This is not like other questions you might find similar. My issue is way bigger.
Scenario:
I have 3 websites. All of them have a common database for authentication and stuff.
Problem is that i will need to expand to 2 more sites, which means more maintenance in login screens and so on. So i will dedicate time to make a "central website" to manage users, access, etc.
Also, Need to implement OpenId for Microsoft Works accounts (ie, Azure tenants).
DDBB User Model: (Simplified)
All users are in the same central database. Which does not contains
anything non-user related.
User is personal on all applications.
Users can have different Roles
Each "User-Role" is mapped to an application, a server and a
database.
Problem:
Created a site in AspNet Core, without any authentication done so I can do it myself since I found that mapping Aspnet Identity tables was no-go because of incopatibilities and overriding is way to complicated, specially when dealing with Managers.
So, Tried and got working a simple Authentication page using HttpContext.Authentication.SignInAsync and CookieAuthentication. Which works well and there is no need to use any of the Identity's implementation (which is not compatible with my backend).
But then I added UseOpenIdConnectAuthentication to have the OpenId auth, but I have no idea how to use it since its suposed to work out of the box when using Identity and when checked documentation they use this code in an controller action: signInManager.ConfigureExternalAuthenticationProperties and I do not have any SignInManager since Im not using Aspnet Identity.
Questions:
Is coping the source of ConfigureExternalAuthenticationProperties to make it work in my site an aceptable solution?
Should I continue to override all SignInManager methods and also probably implement other classes to make Aspnet Identity work with my model?
Tried Mapping the properties to my columns just to test it out and it gave me non debuggable errors, which i dont like to even think about the problems this can give me in the future. For example one error was that it coudnt parse byte[] to string.
How can I implement Microsoft Work Accounts authentication and Database authentication in the same AspNet Site?
Bonus topic
Recently I feel like programming is becoming Configuring instead of coding. Is it just me? Are we now Professional Configurers?
Thanks
The "dream" is to use WindowsAuthentication for an intranet site. However, we need to hit a 3rd party service to determine if the user has "permission" to use the site, thus "Roles". I have seen many examples that show how to add roles to the identity but they are all on "per request" basis. I don't want to do that. I would like for the user to hit the site once, I determine if the user has the permission, and add the role to the identity. The identity (with the role) sticks around for the session. I also don't want to have to cache users and their permissions. Is this doable or am I missing something?
Thanks.
The solution is to write your own Authentication and put caching in the middle. It is really easy to do as I have two methods of doing it.
Pre ASP.NET MVC 5
http://tech.pro/tutorial/1216/implementing-custom-authentication-for-aspnet
ASP.NET MVC 5+ OWIN
http://www.khalidabuhakmeh.com/asp-net-mvc-5-authentication-breakdown-part-deux
My posts describe the basics of writing your own authentication, but it is pretty easy to integrate a third party service once you understand the basics. Hope that helps :)
I'm working on an MVC4 site using SimpleMembership to handle user accounts and role based authentication. We have another site and we'd like to implement a single sign on system allowing users from the existing site to log in to the one I am building. What would be the best way to achieve this and hopefully leverage to the existing roles based authorization I'm using on the MVC4 site. Is it possible to have multiple membership providers (i.e. use the built in one and if the user is not found, attempt to authenticate via a custom provider that I'll write (once I work out how!). Or would it be better to abandon the built in membership/roles and roll my own?
I also thought of letting WebSecurity check the local database and if the user is not found, query the 2nd database and if the users credentials are valid, create a local account for them. One issue with this approach is if a user called Fred registers on the MVC site, and then a user from the other site called Fred logs in, we couldn't create them a local account with the same username. We could prefix/suffix the username with some text to indicate that they are from the other site but then we lose the single sign on feature.
We will also want to integrate AD authentication for staff in the future.
So essentially I'm looking for the best way to authenticate users from multiple databases and keep using roles based authentication?
I've also done a little digging was wondering if ADFS might be useful for this.
Any help or advice would be greatly appreciated!
I recommend the use of an Identity server to handle all your login request and switching to a claim based authentication instead of a role based authentication if you can.
I personally went with Thinktecture IdentityServer
pluralsight.com have a good course on it.
Thinktecture IdentityServer is build on top of simple Membership and it supports multiple protocol such as
WS-Federation
WS-Trust
OpenID Connect
OAuth2
ADFS Integration
Simple HTTP
I recommend checking it
Good Luck
I've asked similar question here because I thought the problem was in my custom membership provider.
Then I tried this:
I created two NEW asp.net MVC applications. In first one, I registered as new user using default membership provider. I closed this application, opened second one and ran it. In this application I was also logged in as user I created in first application. Logging in as user from other application doesn't work, but caching is remembered on this site. Why is it so? Is it a bug?
I think this can be expected behaviour:
If you open localhost/app1 and localhost/app2 you are on the same domain. So its valid that the same cookie is sent. I am not shure if localhost:5050 localhost:5060 are considered as the same domain. But I guess thats the case.
If the same cookie is sent the Memebershipsystem will evaluate this as the same user. Thats expected behaviour.
If you want to have these 2 webs use different pools of users you have to create a new application in the Mebershipsystem and configure it in web.config.
This will not affect the behaviour of a production system, because the 2 web will be on a different domain. each domain is only allowed to access its own cookies.
Are there any decent examples of the following available:
Looking through the WIF SDK, there are examples of using WIF in conjunction with ASP.NET using the WSFederationAuthenticationModule (FAM) to redirect to an ASP.NET site thin skin on top of a Security Token Service (STS) that user uses to authenticate (via supplying a username and password).
If I understand WIF and claims-based access correctly, I would like my application to provide its own login screen where users provide their username and password and let this delegate to an STS for authentication, sending the login details to an endpoint via a security standard (WS-*), and expecting a SAML token to be returned. Ideally, the SessionAuthenticationModule would work as per the examples using FAM in conjunction with SessionAuthenticationModule i.e. be responsible for reconstructing the IClaimsPrincipal from the session security chunked cookie and redirecting to my application login page when the security session expires.
Is what I describe possible using FAM and SessionAuthenticationModule with appropriate web.config settings, or do I need to think about writing a HttpModule myself to handle this? Alternatively, is redirecting to a thin web site STS where users log in the de facto approach in a passive requestor scenario?
An example of WIF + MVC is available in this chapter of the "Claims Identity Guide":
http://msdn.microsoft.com/en-us/library/ff359105.aspx
I do suggest reading the first couple chapters to understand all underlying principles. This blog post covers the specifics of MVC + WIF:
Link
Controlling the login experience is perfectly fine. You should just deploy your own STS (in your domain, with your look & feel, etc). Your apps would simply rely on it for AuthN (that's why a app is usually called a "relying party").
The advantage of the architecture is that authN is delegated to 1 component (the STS) and not spread out throughout many apps. But the other (huge) advantage is that you can enable more sophisticated scenarios very easily. For example you can now federate with other organization's identity providers.
Hope it helps
Eugenio
#RisingStar:
The token (containing the claims) can be optionally encrypted (otherwise they will be in clear text). That's why SSL is always recommended for interactions between the browser and the STS.
Notice that even though they are in clear text, tampering is not possible because the token is digitally signed.
That's an interesting question you've asked. I know that for whatever reason, Microsoft put out this "Windows Identity Foundation" framework without much documentation. I know this because I've been tasked with figuring out how to use it with a new project and integrating it with existing infrastructure. I've been searching the web for months looking for good information.
I've taken a somewhat different angle to solving the problem you describe.
I took an existing log-on application and integrated Microsoft's WIF plumbing into it. By that, I mean that I have an application where a user logs in. The log-on application submits the credentials supplied by the user to another server which returns the users identity (or indicates log-on failure).
Looking at some of Microsoft's examples, I see that they do the following:
Construct a SignInRequestMessage from a querystring (generated by a relying party application), construct a security token service from a custom class, and finally call FederatedSecurityTokenServiceOperations.ProcessSignInresponse with the current httpcontext.response. Unfortunately, I can't really explain it well here; you really need to look at the code samples.
Some of my code is very similar to the code sample. Where you're going to be interested in implementing a lot of your own logic is in the GetOutputClaimsIdentity. This is the function that constructs the claims-identity that describes the logged-in user.
Now, here's what I think you're really interested in knowing. This is what Microsoft doesn't tell you in their documentation, AFAIK.
Once the user logs in, they are redirected back to the relying party application. Regardless of how the log-on application works, the WIF classes will send a response to the user's browser that contains a "hidden" HTML input that contains the token signing certificate and the user's claims. (The claims will be in clear text). At the end of this response is a redirect to your relying-party website. I only know about this action because I captured it with "Fiddler"
Once back at the relying party web site, the WIF classes will handle the response (before any of your code is run). The certificate will be validated. By default, if you've set up your relying party web site with FedUtil.exe (by clicking "Add STS Reference in your relying party application from Visual Studio), Microsoft's class will verify the certificate thumbprint.
Finally, the WIF framework sets cookies in the user's browser (In my experience, the cookie names start out with "FedAuth") that contain the users claims. The cookies are not human readable.
Once that happens, you may optionally perform operations on the user's claims within the relying party website using the ClaimsAuthenticationClass. This is where your code is running again.
I know this is different from what you describe, but I have this setup working. I hope this helps!
ps. Please check out the other questions I've asked about Windows Identity Foundation.
UPDATE: To answer question in comment below:
One thing that I left out is that redirection to the STS log-on application happens by way of a redirect with a query-string containing the URL of the application the user is logging in to. This redirect happens automatically the first time a user tries to access a page that requires authentication. Alternatively, I believe that you could do the redirect manually with the WSFederationAuthentication module.
I've never tried to do this, but if you want to use a log-on page within the application itself, I believe the framework should allow you to use the following:
1) Encapsulate your STS code within a library.
2) Reference the library from your application.
3) Create a log-on page within your application. Make sure that such page does not require authentication.
4) Set the issuer property of the wsFederation element within the Microsoft.IdentityModel section of your web.config to the login page.
What you want to do is an active signin. WIF includes WSTrustChannel(Factory) which allows you to communicate directly with the STS and obtain a security token. If you want your login form to work this way, you can follow the "WSTrustChannel" sample from the WIF 4.0 SDK. Once you have obtained the token, the following code will take that token and call the WIF handler to create a session token and set the appropriate cookie:
public void EstablishAuthSession(GenericXmlSecurityToken genericToken)
{
var handlers = FederatedAuthentication.ServiceConfiguration.SecurityTokenHandlers;
var token = handlers.ReadToken(new XmlTextReader(
new StringReader(genericToken.TokenXml.OuterXml)));
var identity = handlers.ValidateToken(token).First();
// create session token
var sessionToken = new SessionSecurityToken(
ClaimsPrincipal.CreateFromIdentity(identity));
FederatedAuthentication.SessionAuthenticationModule.WriteSessionTokenToCookie(sessionToken);
}
Once you have done this, your site ought to behave the same as if passive signing had occurred.
You could use the FederatedPassiveSignIn Control.
Setting your cookie like this:
FederatedAuthentication.SessionAuthenticationModule.WriteSessionTokenToCookie(sessionToken);
Doens't work for SSO to other domains.
To cookie should be set by the STS not at the RP.