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.
Related
I have an ASP.NET Core 2.0 Web API which will run in a very-high security corporate AD environment (no Azure, no Azure AD, which makes Googling for a solution useless).
The API uses JWT auth, and the client will be an Angular 2+ SPA.
What is the easiest way to issue a token?
My initial thought was to set up an authentication endpoint with Windows Authentication that issues the token and populates the claims appropriately.
Is this the best solution?
Or is there another way I can get the JWT token issued without connecting to any external (internet) services?
Working through this exact thing myself. What we have is a local login and a domain login. The local just authenticates to the DB and the Domain authenticates out to an LDAP. Basically what I am doing is issuing the token based off of a positive authentication regardless if it is the LDAP saying its okay or the DB saying its okay. Here is an example for the DB side of it .NET Core JWT Authentication. The LDAP logic itself is the same it always has been with DirectoryServices etc. There are a ton of examples on here and elsewhere for that, but to answer your question directly set the token issuance based off of a good authentication to AD instance. Separate the two logic sets and you should be good to go.
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
I've been scratching my head over this issue for over a week. We have a web app that we would like to implement SSO for. SSO with windows active directories of our clients (i.e. we essentially need to authenticate against our clients' active directories without much trouble)
The only thing I am 100% sure about is that I will needed a security token service that will have to communicate with an Identity Provider. My question:
Which service is most suitable for the above scenario (AD FS? OpenID & OAuth 2.0? SAML 2.0 and shibboleth?)
How will I connect to the active directories of the clients? Maybe I'm not understanding how the STS is to be used, could anyone clarify? I'm working with an Azure Web App
Will there have to be a different IdP for each client? Will the client have to do more than just give us standard information? What would this info be?
...should I be using Windows Identity Foundation?
HELP :( ... this is an SOS
If anyone could clarify at all, I will forever be grateful. I normally upvote anything I find helpful and accept whichever answer is the best so feel free to answer with what you think might be useful in helping me understand how I can achieve what I am after.
These are the three options I know:
As you mention one option is ADFS this solution means that your customers should install and expose Adfs. ADFS means Active directory-Federation Services, so in this case your application needs to speak WS-Fed (not oauth). Typically if the user is inside the LAN adfs uses integrated auth, if not it will prompt credentials.
WAAD is a new service from Azure, it allows companies to expose their directories to use in cloud applications. With this approach your customers need an account in Azure, create a directory and use the dir sync agent. Your application will talk SAMLP with WAAD.
Auth0 is an authentication broker that allows developers to use social but also enterprise identity providers like AD but also google apps, waad, adfs, salesforce, etc. if your customer only has AD you will provide him an msi for a windows service, that will bridge the company AD with your auth0 account, you can have as many AD as you want. Your application speak oauth with Auth0. This agent supports kerberos authentication as well. The following graph explains this solution:
Disclaimer: I work for Auth0.
WIF doesn't support SAML or OAuth.
Your application is in Azure.
Suggest add WIF to the application and then "bind" to Azure Active Directory. In VS 2013, use the "Change Authentication" feature for this.
Make the application multi-tenanted.
Each customer has their own tenant. User DirSync to sync. each customer AD with their AAD tenant. (That gives same sign-on). Adding ADFS to each customer gives single sign-on.
However, the customers will probably push back on this because of perceptions around security.
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