I wanted to find out if ADFS2.0 provides a way for users to be authenticated with a Custom Store? Version 1.0 you could only authenticate users in the Windows domain, using Forms/Windows Integrated/Cardspace. I have an ASP.NEt website, which I would like the users to be authenticated against a custom store in SQL and then ADFS2.0 to take care of the claims issued to the user...
That's not entirely true. While in its default form, ADFS v2.0 only allows you to authenticate against Active Directory, there is a hybrid approach. You can set the authentication type to forms (modify the Web.config file of the ASDFS server in the \inetpub\adfs\ls directory).
Once set to forms, you can actually customize the ADFS signin page (FormsSigninPage.aspx) to do whatever custom authentication you want. Once the authentication passes, the rest of ADFS will pick back up where you left off.
Here's an article showing how to do exactly that:
Customizing the ADFS Signin Pages
(Information duplicated from another answer of mine, since the same answer applies here.)
The solution that is suggested in another answer to this same question is a bit misleading. If you read the actual blog post you see that they add an extra STS. AD FS 2.0 has a 'Claims Provider Trust' for that other STS, and redirects to it (if the 'home realm discovery' is set up correctly). That other STS then performs the authentication in whichever way it likes, sends a token back to AD FS, which then runs its claim rules.
So in that solution it is not AD FS 2.0 authenticating against an alternative store, but redirecting to an STS which authenticates against that store.
AD FS 2.0 itself does not allow authentication against a custom authentication store. (See this answer of mine for the official documentation at this point.)
ADFS 2.0 can only authenticate users in Active Directory. It can retrieve attributes from other stores (SQL, LDAP, custom), but not for authentication.
You might want to look at StarterSTS (http://startersts.codeplex.com/) as an alternative.
Eugenio
Related
In ASP.NET Core Startup in Configure method when you are configuring piplelines you can use UseIdentity from ASP.NET Core Identity or you can use UseCookieAuthentication. Both of them provide cookie based authentication.
I want to know what is their difference. Is UseIdentity uses UseCookieAuthentication internally? What are advantages and disadvantages of one over another?
Thanks for your explanations.
From the docs which can be found here and here.
Cookie Authentication Middleware:
ASP.NET Core provides cookie middleware which serializes a user principal into an encrypted cookie and then, on subsequent requests, validates the cookie, recreates the principal and assigns it to the User property on HttpContext. If you want to provide your own login screens and user databases you can use the cookie middleware as a standalone feature.
Identity:
ASP.NET Core Identity is a membership system which allows you to add login functionality to your application. Users can create an account and login with a user name and password or they can use an external login providers such as Facebook, Google, Microsoft Account, Twitter and more.
In short Identity builds on just local authentication and provides the ability to perform external authentication as well as baked in solutions for provisioning user accounts.
The pros and cons of each differ depending on your business and both have their own place which I find is usually determine on a case by case basis.
The inner workings for Identity can be found on the github page here.
Is UseIdentity uses UseCookieAuthentication internally?
Yes.
However, both UseIdentity and UseCookieAuthentication will be deprecated in Auth 2.0.
UseIdentity
UseCookieAuthentication
services.AddCookieAuthentication() and app.UseAuthentication() will be used instead.
Important note: Don't use UseCookieAuthentication, if you have UseIdentity. I mixed them together in a project. Claim-based authorization redirected user to LoginPage instead of AccessDenied page.
We have an existing MVC application which is used by multiple customers.
Currently, each customer is given a URL to our application e.g. https://myapp/mycustomername.
When they go their, they are presented with a login screen.
For some customers (not all) we want to implement SSO, and authenticate their users against their active directory, so that they never see the login screen (unless the SSO authentication fails).
Most customers won't be using this functionality.
My first question is: is this do-able? Is it possible to have an MVC application which uses both SSO and forms authentication?
If so, can anyone point me to any links explaining the process?
I've seen some good information, such as this tutorial but I can't find anything that matches my scenario.
Thanks.
This is surely a do-able task.
The steps would be
Identify the tenant name from the URL
Get the Identity Setting
If forms authentication, show them the login page
If SSO enabled, redirect to their ADFS URL
When you onboard your tenant, you will have to maintain the following metadata
TenantName
AuthenticationType : {forms / ADFS}
SSO Url
SSO Federation Metadata URL
etc
We did one such implementation that supports ADFS, Social Logins with Forms Authentication too.
I've a question about oauth2 and its suitability in this case. I've looked at the authorization flow, but that always seems to start the process from the 3rd party web app, not from the portal (auth server)...
My terminology...
1) We have Enterprise Portal system (e.g. SharePoint etc), let's call it portal.com
2) We have a 3rd party hosted web app, let's call it webapp.com
A user, already logged in (authenticated) in portal.com clicks a link on one of the portal pages that opens up webapp.com (my 3rd party, cross domain web app). I want to authorize the user to use webapp.com without the need for supplying any extra login credentials.
Questions:
a) is oauth2 the most common 'standards' based way to do this? Or have I misunderstood something.
b) If it is, what is the authorization flow? (I only seem to find auth flows that start from the user visiting webapp.com FIRST, then directing to portal.com to login, then redirecting back. But in my user story, the user visits portal.com first and is already logged in when they are linked to webapp.com).
Apologies if my terminology is poor - I am new to this area.
Cheers,
Ollie
Technically OAuth 2.0 has been created as Authorization protocol, but it is easily usable for Authentication (Identity Provider) as well and suits your situation rather well. You may however investigate OpenID Connect (OIDC) - which is an extension of the OAuth 2.0 exactly in the area of Authentication / Identity Provider.
If you have got a User Session on your Portal, then it is absolutely fine if you simply redirect to your WebApp and then the WebApp (which has no session yet) requests User Identity from the Portal by the means of OAuth 2.0 / OIDC. User would get extra 2 redirects without noticing anything but this way the login would also work fine if user bookmarks your WebApp and accesses it without first entering portal.com.
It sounds you are looking for a solution of single sign-on. If so, OAuth 2.0 (RFC 6749) cannot help you. OAuth 2.0 is a specification for authorization, not for authentication. It explicitly states as follows.
The way in which the authorization server authenticates the resource owner (e.g., username and password login, session cookies) is beyond the scope of this specification.
Authentication deals with information about "who one is". On the other hand,
authorization deals with information about "who grants what permissions to whom". So, OAuth 2.0 is not the keyword for your case.
I'm trying to figure out what I need to do in order to achieve seamless SSO sign up.
When an administrator of a domain installs my google app, all of the users on his/her domain, should be able to sign-in through SSO without seeing any confirmation prompts. I'm looking into documentation on how to set this up:
Instead of displaying a confirmation page, your application should
match the value of the openid.realm parameter in the OpenID request
against the value declared in the application's manifest.
Is there an example of this? Also, I think Google stopped using XML manifest files once they switched from OpendID to OAuth 2.0. If so, how does this whitelist process work with OAuth 2.0?
Should I be utilizing Google Admin SDK?
Since google is moving away from OpenId, white listing instructions are obsolete. Found a blog post about Domain-wide delegation with Oauth 2.0. Google recommends the following:
the recommended authorization mechanism is now to use OAuth 2.0 and
service accounts. Google Apps domain administrators can delegate domain-wide authority to the service account’s credentials for a set of APIs. This results in allowing the application, by using the service account’s credentials, to act on behalf of the Google Apps domain’s users.
instructions on how to set up domain wide delegation - https://developers.google.com/drive/web/delegation
you can find detailed step to achieve seamless SSO sign up at the following url
http://david-codes.blogspot.com/2014/07/how-to-provide-seamless-single-sign-on.html
Has anyone succeeded in configuring ADFS2 to use Live Id (or Google, Yahoo etc) as a Claims provider, and if so where did you get the configuration instructions (can you share them please)
I have previously manged to do this with ACS in Azure to connect to Live Id and ADFS, but would like use ADFS as the "HUB"
AD FS 2.0 itself does not allow authentication against a custom authentication store: it can only authenticate Active Directory accounts. (See this answer of mine for the official documentation at this point.)
A solution is suggested in an answer to another StackOverflow question, although the wording is a bit misleading. If you read the actual blog post you see that they add an extra STS. AD FS 2.0 has a 'Claims Provider Trust' for that other STS, and redirects to it (if the 'home realm discovery' is set up correctly). That other STS then performs the authentication in whichever way it likes (e.g., using a Google or Live account), sends a token back to AD FS, which then runs its claim rules.
So in that solution it is not AD FS 2.0 authenticating against an alternative store, but redirecting to an STS which authenticates against that store.
This is possible with a custom STS you federate your ADFS with.
The idea is to build an STS which itself uses OAuth2 to authenticate users and then (optionally) performs its own Active directory queries to find a user with the same email address and reads roles from the AD. Then the custom Sts returns all the claims to your application.
As Marnix points out, a hybrid approach is possible where the credentials are provided on the adfs page rather than the identity provider page. This is rather difficult as it involves setting up the wstrustfeb2005 endpoint on your sts. I have a six part tutorial on how to do this:
http://netpl.blogspot.com/2011/08/adfs-20-quest-for-customizing-adfs-sign.html
Nonetheless, the latter approach is much more difficult while exposing a passive sts federated with the adfs should not take you long time.