When adding your Website to a new SSO (AD, Ping on this case), AD will normally ask for one thing: "Please share the Metadata URL for your site."
My application uses WS-Federation and its hosted on IIS. Its an application built in 2013 and minimal code changes are preferred.
Currently the (old) application is already enrolled in one AD that is going to be decommissioned, and the old Metadata used in 2013 is nowhere to be found. And so I need a new Metadata to provide to the new AD.
Back in 2020, I've already accomplished this, the WindowsIdentityFoundation SDK 4.0 was available on the microsoft site, and so following this: How to create federation metadata XML for "Relying Party Trust" and "Claims Provider Trusts" for ADFS 2.0 Was possible to create one FederationMetadata file completely valid and accepted by AD for an existing site to be enrolled to a new AD.
At the time I saved all the links/urls that I used, but with the SDK going out of business in late 2020, and some of the example sites, I had saved, are now Not Found. I am stuck.
Now, 2 years later, we do not have WIF SDK anymore, and here I am trying to do the same. For another address/website. To try to understand better a new approach, I tried to create a new application in Visual Studio to see what FederationMetadata.xml is generated by using the VS's Authorization and publishing. But no matter what I do, a FederationMetadata.xml is nowhere to be found, build/release folders, IIS, anywhere.
So, my question:
How to create a new application with a new FederationMetadata file?
Or even better, how to create a FederationMetadata for an already existing Website?
Thank you.
• Firstly, please ensure that ADFS is installed with correct settings in your environment and the ADFS service is reachable from the extranet through public DNS records configured. Once this is achieved, then please check whether your website has the correct website name configured according to the DNS of the IIS server on which it is hosted and joined to the domain.
Once the above things are working fine and are accessible from the intranet as well as extranet by adding the required DNS records in internal as well as public DNS, please ensure that system authentication and security classes regarding Windows Identity Federation framework that provide basic programming model for claims-based authentication is included in the ASP .NET MVC app or not.
• Since, as you said, the WIF SDK is out of business and no longer available, Microsoft has included the WIF classes in .NET Framework 4.5 hence forth and that should be used for claims-based identity and authentication in ASP .NET applications. So, to do this and include the required claims identity principals and assembly packages, please refer to the documentation link below for more information. It will help you in including the classes and namespaces required for security token-based authentication in your application.
https://learn.microsoft.com/en-us/dotnet/api/system.security.claims?view=netframework-4.5.2
Once the above is done, then you can create an ADFS Federation metadata URL by going to the Endpoints section in ADFS workspace. In that, go to ‘Metadata’ section and copy the link given there which states type as ‘Federation metadata’ and add your ADFS service FQDN in the link’s prefix to form the ADFS federation metadata URL, i.e., ‘https:adfsservicename.domainname.com/FederationMetadata/2007-06/FederationMetadata.xml’
• When the federation metadata URL is generated through the ADFS, then open your ASP. NET MVC application in Visual studio and change its authentication to on-premises, then configure the on-premises authority with the federation metadata URL and leave the App ID URI blank to detect the application URI name from the web.config file. Once, that is done, check the ‘System.IdentityModel’ and other classes added in the project directory. Then, configure the application as a ‘Relying Party’ in your ADFS Server and configure the SSO accordingly.
Please refer to the below link for more information on above stated steps of creating an ADFS URL for ASP .NET MVC application: -
https://www.dotnetcurry.com/windows-azure/1158/using-adfs-azure-single-signon-aspnet-mvc
Related
I have configured Azure B2C as IDP via SAML successfully for a single Service Provider. There are many pieces that i don't understand in this setup even though its working.
I will describe what i have so far and then ask questions later.
Let's say I have two Service Providers,SP1/SP2 both require SAML and a page to signup/signin. SP1 requires loyality_id as custom attribute and SP2 requires product_name attribute.
Here's the source code that works.
Credit/Thanks to this blog
Below is the high level summary of the configuration.
SAML for SP1 (Service Provider 1):
Add signing and encryption keys to the B2C tenant
Register Identity Experience Framework applications
Create web app IdentityExperienceFramework in Azure Active Directory
Create native app ProxyIdentityExperienceFramework in Azure Active Directory
Start from starter pack for LocalAccounts as base
Add Saml2AssertionIssuer to the base policy
Add user journey SignInSaml to the base policy
In Extension Policy override "Local Account SignIn" claims provider and add substitute values for "client_id" and "IdTokenAudience" from apps that were created earlier
Policy file with RelyingParty for SP1
This describes the output claims that are added to the SAML response
Signup/signin policies for SP1:
Create built-in signup and sigin policy
Create Application in Azure B2C blade
So far with this setup, I have two Applications in Azure Active Directory for custom policies and one Application in Azure B2C blade for built-in policy.
According to https://learn.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-create-custom-attributes-profile-edit-custom,
Extension properties can only be registered on an Application object
even though they may contain data for a User. The property is attached
to the application. The Application object must be granted write
access to register an extension property.
What is the "Application" the above paragraph is referring to?
What is the purpose of the apps IdentityExperienceFramework/ProxyIdentityExperienceFramework
To setup for SP2, do I need to create separate Azure Active directory apps for IdentityExperienceFramework/ProxyIdentityExperienceFramework? Or can I use the same ones? How do custom attributes factor in this?
How do I setup custom attributes in this case where SAML is through Custom policy and Signin/Signup is builtin policy
In this case, under what App context are the custom attributes created?
I appreciate any pointers.
Thanks
The application is the one created in the section "Creating a new application to store the extension properties".
The apps purpose is to enable sign-in using local accounts. The same apps can be used accross multiple policies.
Custom attributes are related to the application created in app registrations at Azure AD level, and with the permissions detailed in the configuration docs.
In my Github profile, you can find a different implementation of the B2C as SAML issuer scenario: https://github.com/marcelodiiorio/My-Azure-AD-B2C-use-cases.
Tell me if you have more questions.
I'm currently developing a C# MVC Web API to act as a middleman between a Joomla 3.6 site and a SharePoint 2013 server, both installed in IIS 8.5 on Windows Server 2012 R2. Both the Joomla 3.6 site and SharePoint 2013 are already set up and functional, SharePoint has an active development site already set up, and I'm currently working on a SharePoint app/C# ASP MVC Web API to handle any requests between Joomla and SharePoint. This app handles any request, including logins (which are to be verified against Active Directory on a server), file upload/download, and searching users/documents/tags, among others. The C# app/web API endpoints are also only allowed to be called by users logged into the system, except for login.
My question becomes this, then. Put simply, is there any way I can tell the Joomla 3.6 website, when a user attempts to log in to the system (using the login page), to call my login endpoint and/or somehow authenticate with the SharePoint 2013 server? Preferably, I'd like to use my own C# login endpoint to interact with SharePoint in this case, unless that is not possible.
Thanks.
Yes, there is a mechanism provided via Joomla plugins. I've developed authentication plugins for several third party services.
You would develop a user plugin which hooks into the onAuthenticate event, allowing you to intercept and authenticate the user without them being the wiser.
If you need to add additional fields to login for (i.e. domain) you can also hook into the onContentPrepareForm event and add, alter or remove form fields
This is also one use-case where there is pretty decent documentation available.
https://docs.joomla.org/J3.x:Creating_a_Plugin_for_Joomla
https://docs.joomla.org/J3.x:Creating_an_Authentication_Plugin_for_Joomla
https://docs.joomla.org/Plugin/Events
I'm tried to build a new rich application and i'm having some problems designing the authentication process.
I've only two requirements :
An API needs to be available
An ADFS needs to be used to authentication
My first thoughts was to build the API and to use Angular.js for the frontend. However, I can't see how the authentication should work.
My API needs to be available though scripts. As far as I saw, the ADFS authentication always display t the webpage for the authentication process.
API are usually secured with OAuth2. We used an client id and a client secret to generate a token. But I can't have this behavior with an ADFS.
The only solution I see is to provide two authentications behavior with my application. One with the ADFS for the web access and in the web interface, add a possibility to generate a client id and a client secret associated with an user account that could be used for the API to the headless authentication.
Someone has already faced this kind of scenario?
Thanks a lot!
I assume the 'ADFS needs to be used for authentication' really means 'users should be able to use their Active Directory domain credentials to authenticate'.
If that is the case, you should take a look at Thinktecture IdentityServer. It's an OAuth2 authorization server that you can use with a Active Directory identity provider.
P.S. ADFS 3.0 that comes with Windows 2012R2 only supports the authorization code grant, which is not suitable for JavaScript apps.
I have spent many hours trying to get my Silverlight Business application to run on Azure. My findings so far (open to correction)
Asp net authentication works with a Silverlight web application but not if Ria services is added. This is because Azure only allows one form of authentication per hosting and WCF will not work if the authentication mode is not Anonymous. This mean using WebContext is out of the question.
For the same reason passive federated claims authentication (either OpenID or custom STS) will not work with Ria services.
There is some good stuff in the Identity Training Kit. Active federated claims should allow a login popup to by used. Again there is an example in the kit. I initially didn't look at the "Out of Browser" example until I realised that it should work In Browser as well. I created a custom STS which the Web app called successfully, but I got "service not found" - I assume on the return leg.
I have now decided to pull the plug on all this as I need to get my application up and running. The Silverlight client already communicates with my database via Ria Services - why do I need to create extra pipelines when the authentication data is going to be in the same database? Would security be comprimised by simply checking a user name and password against my database? Would the System.ServiceModel.DomainServices.Client.ApplicationServices namespace be useful in this?
Second statement in your list is not accurate. You can use claims based identity with Ria Services. See here:
http://blogs.msdn.com/b/eugeniop/archive/2009/11/22/updated-ria-and-wif-samples.aspx
http://blogs.msdn.com/b/eugeniop/archive/2009/11/25/ria-services-and-wif-part-ii.aspx
We are planning to create two sharepoint web applications using SharePoint 2010 Enterprise Edition.
All Users that have access to web app 1, should also be able to access web app 2.
This authentication shall be powered by server 2003 active directory.
--> do I need to use claims based authentication?
If so --> can I use Windows Based Authentication with NTLM for that?
The only thing I really want is that users navigating from web app 1 to web app 2 (and vice versa) do not have to authenticate twice.
I do NOT want to configure Kerberos if it is not absolutely necessare though...
Can you give me any hints?
Thanks!
EDIT:
ok - I'll try to be more precise:
In our SharePoint 2010 environment, we've got two web applications running
http(s)://humanresources.domain.com
http(s)://sales.domain.com
Both are running on the same IIS and have host headers configured (with wildcard domain certificate for HTTPS).
Both apps provide a link to the other web application (sales -> humanresources and humanresources -> sales)
Now whenever someone logged in to sales navigates to humaresources, I do not want that that person needs to login again. Therefore I thought I would need claims based authentication???...
Please enlight my brain! :D
EDIT 2:
Thank you for your answers!
#Panagiotis Kanavos - yes we have Users accessing the site from outside our environment: 1) Users which have an AD accound and are working on their laptops outside of our building (e.g.: they have been all day at a customer and are working at home for the remaining hours) 2) We plan to have users without an AD Accound --> Forms Based Authentication: (e.g.: customers accessing our TFS 2010 project protals to get an overview of the project). As far as I know, if you want FBA and WIN-Auth you need to configure Claims Based Authentication...
However configuring a Web Application with Claims Based Authentication did not work. I chose "Enable Windows Authentication" together with "Integrated Windows authentication -> NTLM" as we do not have Kerberos configured (and I'd love to leave it like that ;-)).
However the Users could not login to that application sometimes, and five minutes afterwards it worked. Additionally, when I added permissions to an AD user, SharePoint seemed to save the Token instead of the Group-/Account Id:
e.g.: Instead of MyDomain\user1 it saved something like "0|=MyDomain\user1" and for groups it even only saved weird character strings "022-12.3"
Could it be the case, that my 2003 windows AD does not support that?
IF you are using Active Directory and running both sites within your domain you should not be challenged when users go to either site. It just becomes an implementation issue about who has access to what, either via AD Groups or SharePoint groups.
Claims based authentication is a bit of a different animal. You need to have a security token which contains a number of "claims" about the user, for example UserA is a member of HR and UserB is a member of Sales. Based on these claims you can then have your site/application respond correspondingly. Claims based auth is relatively new for SharePoint and Microsoft and is a bit of steeper learning curve. It may make more sense if you have a mixed mode environment, with both AD and Forms Based Users getting access. However with your described heterogeneous environment it doesn't seem like it's needed.
More info on SharePoint 2010 Authentication is available here.
John
The easiest solution is to create an AD group with the users of both sites and add the group as a user to the Members Sharepoint group of each site. This way users will not have to login at all since Sharepoint will detect the identity of the logged-in user automatically.
Why are you asking about login, claims, and why are you using certificates? None of this is necessary in an intranet scenario where the farm and users are in the same domain or if the farm's domain trusts the user's domain. Do you have users accessing the site from outside your domain?