I am currently looking to connect ADFS with GLPI or Centreon , but I found that I can't because these two apps don't use SAML .
I am now focused on how can I connect GLPI or Centreon to Azure AD using Application Proxy to authenticate with tenant Azure AD account.
But after configuration I can't log in to the application itself ..
my main question is of GLPI or centreon are planned to work with Azure AD.
Has someone has worked on this kind of project? It will help me out to have more info.
Centreon doesn't manage Azure AD so far.
No enhancement is visible in the roadmap for this.
However, Centreon supports LemonLDAP::NG as a frontal.
There are 2 plugins available for GLPI that enable SAML authentication.
https://plugins.glpi-project.org/#/plugin/fpsaml
https://plugins.glpi-project.org/#/plugin/phpsaml
I struggled with fpsaml, the configuration was overly complex and required editing configuration files that could be overwritten IIRC. The plugin has not been updated in some time and it was last compatible with GLPI 9.1.3.
I ended up writing the phpsaml plugin using the Onelogin SAML Toolkit. Using phpsaml you can configure all SAML settings from the plugin configuration page. It is compatible up to GLPI 9.6.
You can find more info on github at
https://github.com/derricksmith/phpsaml.
I don't have previous experience in this kind of projects, but I know SAML is supported by GLPI as external auth.
You'll need to setup your apache (or whatever web server you're using to support it and GLPI config would be quite easy.
Related
I am new to Azure and Office Add in. I want to migrate one of my Office add in authentication mechanism. currently the authentication is implemented using Office-JS-helpers. I want to replace this library with any other alternative. Could anyone share the best way to migrate.
Application : Office Add in (Word and Outlook)
Add in is written using React 16+ version
App hosted on service fabric in azure
Authentication enabled using Azure AD
Note : I am Looking for SSO Authentication mechanism.
The Overview of authentication and authorization in Office Add-ins section in MSDN explains how to build and configure Office Add-ins to successfully implement authentication and authorization. You are interested in the following - Enable single sign-on (SSO) in an Office Add-in.
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
Is someone already configure Google Workspace working with Snowflake and has user automatically created (as Okta can purpose)
Thanks for the help
If GSuite support SCIM, Then One thing that you may try is Custom SCIM integration as suggested here- https://docs.snowflake.com/en/user-guide/scim-custom.html
Currently, Custom SCIM integrations are supported for identity providers that are neither Okta nor Microsoft Azure AD.
Although I've not tested this with Gsuite, you may give it a try provided Gsuite has support for SCIM.
Google Workspace supports SCIM autoprovisioning on SAML apps that are already part of their Pre-integrated SAML apps catalog, although this is not explicitly mentioned in their documentation, Automated user provisioning is available only for Supported apps:
See About automated user provisioning
Snowflake would need to work with Google Workspace to see if their solution could be added to the catalog.
I'm investigating options for adding AzureAD authentication to Angular SPA application with .NET core backend. I'm using VS 2019 MVC project with Angular (same as dotnet new Angular is producing). It's using .NET Core 3.1 and Angular 8.
From what I learned so far I have 3 options:
Built in Azure App Service Authentication
Adal.js - looks like the older brother of,
MSAL.js - which after making it work locally with Azure AD I learned on this page that "At this time, AAD V2 (including MSAL) is not supported for Azure App Services and Azure Functions. Please check back for updates." I couldn't make it work on Azure today so maybe this Note is for a good reason.
EDIT: Interestingly now point 3 works for me on Azure App Service so I'm not sure what this note means.
My requirements so far are that no screen is accessible to users unless they log in and that I will be able to read information about them from Azure AD - Roles, groups.
I never worked with Angular and I don't have any experience with Azure AD and I need someone that implemented it already to at least tell me which option I should choose and I can go from there.
My requirements so far are that no screen is accessible to users unless they log in and that I will be able to read information about them from Azure AD - Roles, groups.
I think the option 1 could meet your requirement, the configuration of Azure AD in Authentication / Authorization is higher than your code, the user could not access the app unless they log in.
To read the information about the roles, groups, you could check this good blog.
Here you have an angular E2E auth scenario using App Service built in authentication:
https://learn.microsoft.com/en-us/azure/app-service/app-service-web-tutorial-auth-aad
I believe the part you are interested in is this one:
Enable authentication and authorization for front-end app
This way app service is the one redirecting you to AAD and getting a valid token that you can just pass in to your APIs afterwards. If the APIs are hosted in App Service as well, then APP service will be the one validating the token for you, so your backend code does not need to worry about authentication (you still need to handle authorization)
I am a beginner with ADFS and do not know where to begin. I have an AngularJS 1.4.9 application which makes Ajax calls to an ASP.NET Web API 2.2 service.
Both applications are hosted within IIS under the same site and both use Windows Authentication on my company’s intranet. I’d like to modify them to use ADFS so that these applications can be accessed from the internet without a VPN.
You are better off looking into using the web application proxy (WAP)functionality for now. WAP allows publishing internal resources and making them internet accessible.
Once you get AD FS and WAP deployed, see step 3 in https://technet.microsoft.com/en-us/library/dn280943.aspx#BKMK_3
You can then look to slowly updating your applications to use federated authentication with AD FS.