Enable anonymous access to ADFS 2.0 SharePoint site - sharepoint-2007

I have a SharePoint 2007 portal configured to authenticate againsts a STS (ADFS 2.0) using the FormsSignIn (Forms Authentication on the ADFS). Is there any way to have a few pages living in the SharePoint portal that allow anonymous access? I've tried checking the "Enable Anonymous Access" in the SharePoint Central Admin, and I've tried adding location sections in the web.config, but both of these still redirects to the ADFS login page.
I have re-branded the ADFS login site so it looks less generic and more like our SharePoint login page. Should I just move those anonymous access pages out of SharePoint and into the ADFS site?
ADFS is new to me and I'm not sure what the best practices are for customizing the login process.
Thanks,

After a couple days without an answer, I re-posted this question on SharePoint.SE. After re-enabling allow anonymous access, I was able to get to these pages. Although, I am getting an internal error 500 for all stylesheets that are in the /Style Library/ library. So I'm not sure if I'm that much better off.

Related

How to set the redirect URL to a specific domain when successfully logged in with ADFS?

I'm authenticating users trough ADFS using OWIN in ASP.NET MVC.
I use the same ADFS server for two diferent sites.
The first site is www.mysite.com and the ADFS authentication works propertly.
The second site is www.mysiteadmin.com (the administrative site), but when the user succesfully logs-in in the ADFS site, the redirection is made to www.mysite.com and not to the "admin" site.
Does someone knows why is this happening. I asked to the ADFS Service owners and they said that both sites are registered as relying party trust.
I want to specify the respective redirection URL on each site, but I haven't found anything helpful over the internet.
Thank you very much!
If both sites are set up with RP trusts and both have the correct redirect URI this will work.
These are separate applications?
It sounds like both sites have the same URI?

Azure AD Authentication from ASP.NET MVC

I am struggling to find if I can authenticate my users with Azure AD using ADAL in a MVC Web Application directly.
I have the application setup and working. When a user hits a page requiring authorization it redirects to MS to login, then redirects back just fine. I need to host the login form.
Is this supported? I find a lot of misleading information and no definitive documentation or examples.
Thanks in advance.

Thinktecture IdentityServer V3 without Sign in page

I am spiking a solution with Thinktecture IdentityServer V3. The setup of the project is an Asp.net MVC 5 site which uses forms authentication to authenticate the user, we also have a number of web api sites which are hosted seperately.
I would like to use IdentityServer to SSO into the web api sites. this is an internal solution and would like to somehow programatically login to the identity server instead of been shown the login screen.
Is this possible?
Many thanks
Check this link.
https://github.com/IdentityServer/IdentityServer3/issues/831.
You can sign in as resource owner, but SSO won't be possible.
We can always customize the login page provided on IdentityServer.

Supporting ASP.NET forms authentication for extranet users and ADFS federated login for intranet users

I am developing an asp.net MVC web application that will be deployed in the cloud and should support the following authentication scenarios:
Transparent authentication for domain users on an intranet. These users should be able to access the application without signing in.
Forms login for arbitrary non-domain users on the internet. These users should be presented with a login page using Forms authentication, and membership is managed internally by the application.
Forms login for domain users on the public internet. They should be able to use the same login form as non-domain users, but sign in with their domain credentials instead.
Active Directory Federation Services (ADFS) with passive authentication can cover cases #1 and #3. Since it redirects to the federation provider's login page, it doesn't cover the #2 case. I understand active authentication by my application could possibly support all three cases, however there is not much documentation around on how this would be implemented.
Ideally there should be a way for my application to authenticate a domain username and password with the ADFS federation provider.
Does anyone know whether this is possible, and if so, how?
The standard pattern for this is ADFS with a split DNS - IWA for intranet and Forms for internet.
However, ADFS can ONLY authenticate against AD so option 2 can't be achieved.
I would suggest using IdentityServer for option 2 - you may have to customise it depending on your "flavour" of membership - and then federate ADFS and IdentityServer.
IdentityServer is free / open source.
To expand on nzpcmad's answer, you can set up Claims Provider trusts other than Active Directory in the ADFS Management console under Trust Relationships > Claims Provider Trusts, they effectively chain ADFS with custom STS services.
The entries you add will be added to the Home Realm discovery page within the ADFS web site, such that authenticating users will be presented with a drop-down list to essentially choose the Claims Provider they wish to be authenticated against.
Automatic sign-in will still work for internal users who choose your Active Directory (ADFS provider), whilst members of other Providers will be redirected to their chosen Claims Provider's web site, which will typically present a Forms login page and authenticate against a back-end membership database, all external users (who are not able to present an NTLM or Kerberos token will be required to enter their details - for AD users this will mean they have to enter their domain\user string (or user#domain) and internal password.
Of course, you have to create these providers yourself, in the old WIF days this meant using the fairly clunky Custom STS template, however you can now streamline the procedure with a simple OWIN-based MVC5 site. Alternatively, as nzpcmad suggests, you could look at using IdentityServer.

Username and password authentication for WIF (Windows Identity Foundation) in ASP.NET MVC

We have two existing legacy web applications, one for the intranet using windows authentication within the domain, and one internet application, performing a custom web forms username + password based authentication. Now a new web applications is developed and will be available in the internet to both internet and intranet users, handling both authentication models. Therefore we decided to use WIF. We're going for ASP.NET 4.5 MVC 4 on Windows Server 2012.
The intranet authentication shouldn't be a problem as we can use ADFS 2.0 here.
But we currently have no clue how to solve the username + password authentication. It looks like we need to develop a custom UserNameSecurityTokenHandler to authenticate users which provide username + password information which is verified against our custom membership provider. But I need some assistance with the whole workflow...
Assume that we have a custom login page for internet users; and assume that we managed to route internet users to this login page (in ASP.NET MVC), what's the missing part from here to a valid token? How would the form or the MVC controller action which received the provided username + password proceed to trigger the configured WIF identity provider?
The most elegant solution would be to create another STS for the external users and have ADFS trust this as an identity provider:
External users will be redirected to the IdP STS that would use the usr/pwd database. Internal users will authenticate through ADFS directly (against AD).
In this scenario, ADFS is acting both as an IdP and a Federation Provider.
For this to work you need both ADFS and the IdP (and the app) exposed to the internet. An STS you can use that leverages membership is IdentityServer, which is open source and you can of course customize for your needs.
With this architecture you don't need any special customizations/extensions in the app. You will need to handle "home realm discovery" though. Which is the process of knowing where to authenticate users on (e.g. intranet vs. extranet). Presumably, you might have different URLs, etc.

Resources