We have an existing MVC app using the ASP.Net Identity Framework to store user logins/passwords/roles/etc... in a local SQL database. We would like to move the authentication portion of the identity to use a SAML IdP but still build out the IdentityUser object within the Identity Framework with the details from the local database. Essentially the flow would be:
User browses to site -> User is forwarded to IdP for authentication -> User is directed back to site after successful authentication -> Details from local SQL database are retrieved using information passed back from IdP (likely email address) -> Site leverages IdentityUser object with information from local database
I cannot find really any information on this approach, which makes me think it is not possible and/or advisable. Any direction or suggestions would be appreciated.
You could handle the AcsCommandResultCreated notification and then load the IdentiyUser by the email saml assertion
I have an Angular application(ex. https://localhost:44301) that is
using Web API(ex. https://localhost:44302) to interact with data.
I have an Identity Server 4 (ex. https://localhost:44303) for authentication in which we have even
configured external login with Azure AD.
Our Architecture is something like below :
Now I want to add ADFS 3.0 (even ADFS 4.0 i.e. multiple ADFS) as a external login provider
So as per my research I have to go for only OAuth 2.0 with
Authrization Code Grant.
ref: https://github.com/nordvall/TokenClient/wiki/OAuth-2-in-ADFS
For that what type of configuration should I add into ADFS server. I am mainly confused about:
what should add as relying party trust identifier ?
what should as a resource into authorization request ?
what configurations for custom claims ?
There are three ways you can do this.
You can add ADFS via:
SAML 2
WS Fed
OpenID Connect
So:
SAML or you could use the Rock Solid Knowledge stack described in that blog
WS-Fed - use the built-in ASP.NET Core SP option
OIDC is doable but rather go with above
In both these cases, ADFS is a CP to idsrv4. idsrv4 is an SP to ADFS.
If you go with OIDC, it's an application group.
I am looking for Single sign on (SSO) with SAML2 tokens and I have to used ADFS. I can't use WIF.
I googled a lot to understand SSO, SAML2 and ADFS, now I have some doubts which I am not getting.
Scenario: The applications are asp.net MVC application
1. App-A(Windows Authentication) : hosted and it is using ADFS.
2. APP-B(Form Authentication): authenticates the user using the UID and PWD stored in DB.
Do I need a intermediate application to accept the SAML2 token and process it(similar to Identity provider) or it can be done in the App-A itself?
In the App-B what are the things I have to implement to make it aware of SAML2 request(do i need to implement custom handler)?
please help me to choose the right things for the implementation.
--Thanks--
You need a SAML stack for your application.
Refer SAML : SAML connectivity / toolkit and the links in that entry.
For A, perhaps you can use the WIF SAML extension mentioned in the article above?
For B, you need to rip out the DB authentication and add the SAML functionality as for A or else have a look at Identity Server which you can federate with ADFS and which also authenticates using a DB (but doesn't support SAML itself).
Currently, I have an MVC web application that sells widgets. A user logs into our system using forms authentication, and can then do various functions based on the group they belong to(ie Place an order, View an Order, Cancel an Order, etc).
We've been tasked with writing an Api that will give third parties the ability to create and view orders in our system. Each third party will have it's own username and will be limited to certain api methods based upon the group they belong to.
We are looking at using Web Api as a mechanism to provide the api. We would also like to be able to consume this api from our MVC web application. Unfortunately, we are running into issues with Authentication for the Web Api. Using a DelegatingHandler, we have implemented Basic Authentication over SSL for our WebApi. This works great for our third parties. However, when trying to consume the Api from our MVC application we are getting 401 access denied errors because the user was authenticated in the MVC app using Forms authentication, but we have no way of passing those credentials on to the Web Api. Is there a way to pass the Forms Auth credentials from our MVC app to our Web api app?
IIS Setup
WebSite named WidgetStore with two web applications
WidgetStore\UI -uses forms authentication
WidgetStore\Api - uses basic authentication
Is there a way to pass the Forms Auth credentials from our MVC app to our Web api app?
Sure, let's take for example the following MVC controller action calling the Web API:
[Authorize]
public ActionResult CallWebApi()
{
var baseAddress = new Uri("https://example.com");
var cookieContainer = new CookieContainer();
using (var handler = new HttpClientHandler() { CookieContainer = cookieContainer })
using (var client = new HttpClient(handler) { BaseAddress = baseAddress })
{
var authCookie = Request.Cookies[FormsAuthentication.FormsCookieName].Value;
cookieContainer.Add(baseAddress, new Cookie(FormsAuthentication.FormsCookieName, authCookie));
var result = client.GetAsync("/api/values").Result;
result.EnsureSuccessStatusCode();
// now you can read the result.Content ...
}
}
This assumes that you have also enabled forms authentication in the web.config of your Web API project and that the cookie name is the same as the one used in your MVC project.
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.