I created Federation Metadata using FedUtil tool on local, but on adfs server i did not use that federationmetadata for autoclaims I added claims manually.
Now I want to deploy my changes to other enviorment, Can anyone please tell what is the use of FederationMetadata in RP? and how it differs in different enviorment?
The adfs fed-Metadata which I used to configure local RP is having different X509 and other cryptic tags which are different in other adfs federation metadata? Why? Basically what is the use of it and when it come into the picture?
Note: I am using VSTS 2010 asp.net C#, WIF 3.5 and adfs 2.0
The RP metadata for WS-Fed is just a nice-to-have. You can use it to configure the RP on ADFS by importing the metadata but you can do it just as easily by doing it manually. Basically it just contains the entityID and the endpoint.
RP on WS-Fed doesn't use a certificate (unless you chose the encrypt RP claims option).
If you want to hook up the RP to another ADFS just re-import the RP metadata on the new box or do it manually.
Each token minted by ADFS is signed and each ADFS has a different signing certificate which is reflected in the metadata.
Related
We have a an ASP.NET site using OWIN that stores a username\password in the DB and a client has ask if a third party system can authenticate against our data using an ADFS\SAML approach. Can we expose the data held to mimic ADFS\SAML?
Would anyone have a suggestion of how this could be possible? or even better an example of where this has been done?
Thanks
Jake
I assume you mean a 3rd party accessing your data by authenticating somewhere else and then passing a SAML token?
They would be using ADFS?
The problem is that your credentials are in a DB and ADFS requires the credentials to be in AD.
So you would have to be a SAML IDP and federate with ADFS.
This requires you to be the server side of SAML. Most libraries out there are for the client side of SAML.
So you could look at products like shibboleth, IDaaS e.g. Auth0 or commercial stacks e.g. ComponentSpace.
A diagram would be useful to clarify exactly what the use case is.
This is a follow up to my question on ASP.NET MVC / Web API Custom Authentication. The answers I was given told me to investigate claims-based authentication protocols and I've been reading through the following book to try and gain a better understanding of Microsoft technologies that will allow me to do this.
According to the linked book, you can use Active Directory Federation Services (ADFS) 2.0 to issue claims. What isn't clear is whether the users are required to be stored in Active Directory. Let's say I have an existing legacy application which handles authentication and in which user information (username, password, email, etc.) is stored in an Oracle database (as per my previous question), can I still use ADFS to issue claims or will I need to build my own claims issuer (STS) into this existing application?
Given the Active Directory in Active Directory Federations Services it would seem that having the users stored in AD is a requirement but the book also has the following image
and also this
ADFS requires users to have an account in Active Directory or in one of the stores that ADFS trusts.
which is adding to my confusion. Can someone help shed some light on this?
You can use an ADFS Attribute Store and then create a Claims Provider Trust that has claim rules that query the attribute store. This post has someone using a SQL attribute store to SQL and then a linked server to Oracle. There's also a recommendation to use a custom attribute store and query Oracle from it. I've used both types of stores and it's maybe a bit of a question of what do you want to manage and maintain over time, code or SQL. I may lean towards the custom attribute store.
http://social.msdn.microsoft.com/Forums/vstudio/en-US/3418078f-1bb5-4f5f-9d6e-6907d0222600/using-an-oracle-database-as-an-attribute-store?forum=Geneva
In ADFS 2.0, 2.1 and 3.0, it is mandatory to have users in Active Directory for authentication.
Once authentication is performed, ADFS can retrieve user information from any sources to create the token; these sources are called "attribute stores". As shown in your diagram, ADFS provides attribute store for AD, ADLDS and SQLServer. If you need to access other systems such as Oracle, you'll have to build a custom attribute store (there are examples on technet on how to do this).
Note: in the upcoming version of ADFS on Windows Server 2016, you'll be able to authenticate users in any LDAP store.
I am developing an ASP.NET application. I have successfully added an STS reference to a stand-alone AD FS 2.0 server, so I can authenticate against a 3rd party's active directory. The problem is that I have more than one client who wishes to be able to authenticate against their own active directory. It seems that I can only add one STS reference to a project. How do I add multiple identity providers to an ASP.NET application and then programatically choose which provider I want to redirect the browser to for authentication? Thanks!
Ralphie
That's not the normal federation pattern.
You normally "bind" your application to one STS (say STS1) using FedUtil and then at the STS level federate with other STS (say STS2 and STS3). Then when the user accesses the application, WIF redirects to STS1 and you get a "Home Realm Discovery" screen that asks "Who would you like at authenticate against (STS1 / STS2 / STS3).
Your question doesn't indicate whether you already knew this or whether you are wondering how to authenticate against multiple STS.
Update: You can use VS to create a custom STS - not sure if HRD is out-the-box. What other authentication stores do you need to cater for? Why do you think you need a custom STS? You can use multiple instances of ADFS all federated against each other or federate ADFS with PingIdentity or OpenAM ... Have a look at IdentityServer. That's a custom STS which is a very good base to use.
Update 2: Yes - you are correct.
We have ADFS 2.0 running and have federated with various STS.
Is it possible to federate with Windows Live, OpenID and Facebook?
Some of our users already have these types of credentials and it would be a bonus to be able to use them.
If so, what URL would be used for the federation metadata address in the "Add Claims Provider Trust" wizard?
Any other gotchas?
ADFS doesn't natively support the protocols of those IP-STSs (with the possible exception of Windows Live). You'll need to put an FP-STS that understands those protocols (e.g., PingFederate) between ADFS and them.
We have been investigating this question a lot.
It seems that the best setup is to use ACS in combination with AD FS 2.0 as described in this article.
This setup also enables claims transformation, for example, if you want to add the corporate customer number as a claim.
We have not yet seen any examples where you can connect AD FS 2.0 directly to Facebook however.
Yes . there are no direct way to get the claims from ADFS , need to configure the ACS and need to set the ACS as ID providers to ADFS.
But the token validation for ACS is 24 hours at max , so you need to be happy with short-lived token for Social Id providers.
While trying to learn the ADFS 2.0 environment, I created an empty ASP.NET Claims aware application to be the RP using Visual Studio 2010.
using ADFS 2.0 I did the following:
Created a SAML 2.0 relying party using the 'Add Relying Party Trust...' wizard
Created a SAML 2.0 Claim Provider using the 'Add Claims Provider Trust...' wizard
Now I did the following steps:
Pointed browser to http://localhost/adfs/IdpInitiatedSignOn.aspx
Selected the RP defined in step 1 from combo box as the site to sign in.
Selected in the next page the IDP defined in step 2 from combo box as the authenticating site.
Clicked 'Continue to Sign in'
The ADFS 2.0 now, redirects me to the URL configured for the IDP and a SAMLRequest is attached to the request. (which is great)
However, The SAML Request arrived to IDP does not contain any ACS URL (More techninally, there is no XML node of "AssertionConsumerServiceURL"),
Isn't ACS URL is mandatory attribute in SAML Request?
Thanks !
Yoash
No, the ACS URL is not a mandatory attribute in a SAML 2.0 AuthnRequest. This information is typically exchanged in the meta-data when you setup the trust relationship between the IDP and SP. This simplifies the security check the IDP must do if the ACS URL or ACS Index is present (must be the same as the meta-data or AuthnRequest MUST be digitally signed).
We've done quite a bit of interop work with MS WIF/WCF Claims aware applications via our STS as well as SAML 2.0 with ADFSv2 if you'd like some more information.