Last post Mar 06, 2018 07:25 AM by DomenicoL
Oct 26, 2016 01:14 PM|illumna1|LINK
My organization currently uses it's own custom authentication like forms authentication to sign onto our website. We have a customer that has ADFS setup and wants SSO to our application. Our goal is to provide this to the customer but have an open architecture
to permit other customers to do this as well in the future.
My requirements given by management:
So, I've done a ton of research but feel like I am running in circles. For testing purposes, I setup a local ADFS on our test system to simulate it being the customer. I've used
this guy's code example in one of our pages and am redirected to our test ADFS server where I can login with my Active Directory credentials. My credentials are authenticated and I'm redirected back to the page but I do not receive the email claim back.
Most examples that I am seeing are either very broad architectural examples or for my application to connect to my ADFS server whereby we would configure our ADFS server to point to multiple identity providers. Management does not want that so that is a
no go. Other examples I am seeing are also based on configuration-only which won't work. It's my understanding that WIF is supposed to make things easier but I can't seem to figure it out. I have looked for examples but some code examples I have found are
for .Net 3.5 and we are using 4.5.
So, for some questions:
Nov 03, 2016 07:05 PM|gtscdsi|LINK
It's seems like you should look into the Federation Identity of WIF.
First of all, you should keep it in mind that your application should only trust the issuer from your organization and only accept the claims from this issuer at any time for any request.
Secondly the issuer inside of your organization can be ADFS or even asp.net web application, but it must has the ability to authenticate user and setup as a standard WIF issuer.
Finally you can let your issuer trusts other Identity Providers (IP) from other company and make your issuer acting as Federation Provider (FB). Also you need to setup claim translation rule on this FB to let FB understand claim from other IP and create
a new one with claim types only available inside of your organization since your application only accepts claims from FB.
Here is a link for you, it illustrated Federation Identity in details and hope it may help with you.
Mar 06, 2018 07:25 AM|DomenicoL|LINK
we have the same case series that you have illustrated and the way to graft a parameter
whr to run the so-called HRD (Home Realm Discovery) is correct.
Like you, the problem of having to configure different tenants of our application to allow each organization that uses it to use its own ADFS is impractical.
An adoptable solution is to change the STS by engaging a two-time request mechanism of the credentials:
a) username request
b) password request
Between the two steps you will have the opportunity to check which is the correct IP of reference for the specified user, inject WHR and consequently check the behavior and transform the subsequent intermediate claims received to alter or return as they
You probably already verified this with Microsoft or Amazon systems.
Obviously this mechanism is not to be confused with MFA, which is a different scenario. I am afraid, however, that as you have been asked to integrate third party ADFS you may be required to integrate an MFA mechanism on another customer's tenant on Azure.
I hope it can help.