We have an on-premise website at the moment and I need to make it public, but require users to log in with their office 365 username and password.
My problem is that I've looked everywhere and can't seem to find an implementation for ubuntu servers.
I've also seen many instances of syncing office 365 accounts to the on-premise AD accounts, but not the opposite.
Ideally it should be implemented through Single Sign On.
You need to register your website as an Azure AD application, which will provide you with an app id and app secret. Your website will then need to implement the oauth 2.0 flow. Microsoft provides libraries for most platforms but if they don't have one for yours, everything is accessible through REST calls.
There are two most likely approaches to achieve this:
Configure SAML SSO in your application then use Azure AD as the IdP (as in Bernhard's comment). This will allow your application to gain information passed within the Saml token. You'll still need to present the site to the Internet via some sort of reverse proxy
Consider placing your website behind Azure App Proxy. This will allow you to publish the site over the Internet without having to open any firewall ports, and will allow you to use KCD to log users in without having to configure anything in your application, simply enabling Windows Integrated Authentication. This provides two very important benefits: 1) Unauthenticated visitors cannot hit the site at all, providing significant DDoS/attack protection, and; 2) No reverse proxy or other appliances are required, typically
Related
I'm currently integrating SSO into a web application using passport-saml. Still fairly new to this and trying to understand all the nuances that comes with it so I've got a few questions that I can't seem to find the answer to:
Question 1
I guess, there are two aspects to the IdP side of things. 1 for the customer and 1 for the organisation hosting the SP. So as the org that has the SP, we would need to have our own IdP account to upload our application with all the relevant SAML settings (let's say Okta for this example). The customers would then be able to find the SP from the catalogue of applications from whatever IdP they're using where they can add it and can use the generated Identity Provider Single Sing-On URL and X.509 to input into the SP's settings. I know Okta has a setting to enable their users to find organisation-managed applications which they may need to enable to be able to find our application once approved by Okta. Am I correct in thinking this?
Question 2
Would this mean that as an org, I would need a presence on each IdP a customer might use? OneLogin, Okta, Active Directory, etc.
Question 3
Are IdP's the same for the most part? As in, would I just need to implement SAML into my back end and users can just enter the Idp URL and their certificate, and this will just work for any IdP that the users might be using?
Question 4
Is uploading an application to an IdP a paid service? I've currently got a sample project that is using Okta as an Idp, got all the settings set up but I've noticed that I can submit the application on Okta as a software vendor. Obviously I can't go through it since it's a sample project and I'm also using a trial account so I don't actually know what this entails
Question 5
Lastly, as I previously mentioned, I've noticed that Allow users to add org-managed apps is an available setting for users so they may need to enable this to find my application. But I've noticed that there are thousands of applications that I can browse through on Okta while having this setting disabled. So Okta -> Applications -> Browse App Integration Catalog, I can find applications like Dropbox, etc. Is it a different process (than q5) for an application to be visible on this list?
Question 6
Is SSO at user level or at organisation level? As in, can users of an organisation have a mixture of different ways of logging in? Like, user 1 has SSO enabled but user 2 doesn't. Is that how it tends to work? Or is it more so, an admin enables SSO for the entirety of the organisation whole organisation?
I'm still trying to piece everything together but hopefully I've asked the right questions to properly set this all up but any other additional information you want to share would be helpful!
Answer 1: You are correct that as the organization that has the SP, you would need to have your own IdP account (for example, with Okta) to upload your application with all the relevant SAML settings. Customers would then be able to find the SP from the catalog of applications from whatever IdP they're using, where they can add it and use the generated Identity Provider Single Sign-On URL and X.509 to input into the SP's settings. You would also need to enable the setting in Okta that allows customers to find organization-managed applications.
Answer 2: Yes, this would mean that as an organization, you would need a presence on each IdP a customer might use. Different IdPs have different ways of setting up and managing SP applications, so you would need to create an account and configure your application on each IdP that you want to support.
Answer 3: IdPs are not all the same, but most of them support SAML, which is the standard for SSO. By implementing SAML into your back-end, you can allow users to enter the IdP URL and certificate, and this should work for most IdPs. However, you should check the documentation and settings of each IdP you want to support to make sure that everything is configured correctly.
Answer 4: It depends on the specific IdP provider. Some providers may offer free or trial plans for uploading and managing SP applications, while others may require a paid subscription. It's best to check the pricing and plans of the specific IdP provider you're using to see if there are any costs associated with uploading and managing your application.
Answer 5: Yes, there may be a different process for an application to be visible in the app integration catalog. Some IdPs, such as Okta, have a public application catalog that includes a wide range of popular applications that are pre-integrated with the IdP. These applications may be accessible to all users regardless of whether the "Allow users to add org-managed apps" setting is enabled. It's worth noting that the specific process for making an app visible to users may vary depending on the IdP provider you're using.
Answer 6: SSO is typically implemented at the organization level, meaning that all users within the organization will use the same SSO method to access various applications. However, it is possible to set up different SSO methods for different groups of users within an organization.
For eg. an admin can enable SSO for all users within the organization, but also set up a separate SSO method for a specific group of users, such as contractors or partners. This way, users within the same organization can have different ways of logging in. Some IdPs may offer more granular control over SSO settings than others.
We want to use SSO for a group of apps (this will include GitLab, probably Drupal and a bunch of small apps I will write in Symfony for various tasks). We would like to currently use Google accounts to authenticate all apps, but because there are limits (I know you can increase them) on how many apps you can have and Google sometimes change what features are free, it would be good to have the option of using our own login down the track if needed.
I have used SimpleSAMLphp in the past with GitLab (using a database to store credentials) and it worked well. Is there a way that I can use the Google Auth as an IDP and have SimpleSAMLphp record the email address to link the accounts etc and allow me to add things like groups etc in to send down to the app when a login happens? I would put a password field in the login table in the database as well so that if we decide to move away from Google we can generate random passwords and continue without too many issues.
The information I find online is for using SimpleSAMLphp as the IDP for gsuite etc (we will be using general Google accounts, not ones in gsuite) and not the other way around. I also couldn't see any Authentication Modules for Google authentication. Are there any tutorials or instructions anywhere on this?
You can accomplish what you are asking fairly easily. Instead of integrating your SPs with Google directly, integrate them with an SSP idP you control, then set up your authentication page (i.e. the page redirected to by your authsource module) to be an SP for Google. Here's what that looks like:
vendor sp -> your SSP idP -> your login app -> your SSP SP -> google idP
This way you end up with only a single Google integration configured for all your vendor integrations. There are numerous benefits to this approach:
You aren't affected by # of integration constraints imposed by google
Since your vendor SP integrations are controlled on your own server, you can easily move to a different cloud-based idP for authentication in the future without having to re-integrate all your SPs
You can easily give your users alternate sign-in choices if you want.
You aren't constrained to SAML or protocols supported by Google. Many vendors still use proprietary token based authentication. These can easily be supported with this setup.
Happy to help with implementation details if you need it.
I'm using activesync to sync exchange emails, where the authentication happens using basic auth. I was wondering if it's possible to use activesync with a single sign-on solution?
The only way to implement SSO on ActiveSync is with Certificate based authentication. ActiveSync has no support for identity federation, hence no SAML, OAuth, ... Setting up an internal CA is not that complicated, especially if you use Microsoft's CA: ADCS. Simply follow the instructions in the link from BastianW.
You will then need an Enterprise Mobility Management tool like AirWatch, MobileIron, ... to integrate with your CA and distribute the certificates seamlessly to your users.
I assume with SSO you wish to implement a way where your users can use there mobile phones without the need to adjust her password every time when they change there password inside the active directory. The solution to do that is using "certificate-based authentication for Exchange ActiveSync". Via that approach an internal CA will create an certificate for the user which can be used on the mobile device to authenticate an ActiveSync session against your Exchange environment. As long as the certificate is valid the user can use that on there mobile device instead of an password.
Keep noted that this required a higher workload for the IT department (for most my customers) so most of them started to use a MDM environment which can push these certificates to the enrolled devices nearly automatically. AirWatch for example can do that (but there might be other, however I can only speak from AirWatch as this is in use by 6 customers).
And just another advise how we build that: We added additional IPs to the Exchange environment then configured an additional ActiveSync side with certificate authenticated. Then we could test the whole solution and later one switch over the user. But if you do not have that much users you might considering a "big bang" migration.
Simple activesync via BasicAuth is not really "the way".
E.g.: Airwatch is using the "Mobile Email Management", which works like an Proxy to your network. Working that way, you can use SSO via AD / LDAP and so on...
I would highly recommend doing it that way.
I am just learning Mobile Services. I've created a simple one which works fine locally. I published the mobile service to my Azure account. I then tried to access a method on it from the browser and I get a log in dialog. I figured out that I need to provide the application key generated by Azure as the password. Once I do this, it executes correctly. However, is there a way I can execute a method without providing a key? In other words, what if I wanted to expose one or more methods to everyone, without any authentication. How would I do this?
Yes, there is a way. There are four authentication levels in Windows Azure Mobile Services.
scripts and admins
authenticated users
users with application key
everyone
By default, the authentication level is set to "users with application key".
Depending on the backend you use, you either have to specify the auth level in the Management Portal in the data-tab (Javascript) or as a method attribute in your Controller-class (.NET) to "everyone".
Curious what recommendations anyone has.
I have an existing asp.net forms application that does a Forms Authentication and has identity impersonate turned on.
The application has a link to a questionnaire that I would like to develop separately in an asp.net MVC application, but I don't want the users to click on the link and be prompted for a username and password, I would like them to be able seamless start filling out the questionnaire.
Is there a way to somehow transfer authentication from one .net app to another? I would like to be able to pass stuff like UserRole.
What's the best way to do this?
If you use the same MachineKey in both applications and the MVC application is on the same server, I think that it will reuse the auth cookie and simply consider them logged in. See this MSDN article on configuring the MachineKey, especially the section on sharing authentication tickets across applications. Note this assumes that both applications are on the same server. If they are on different servers then you'll need to investigate some other mechanisms -- say generating a single-use ticket for the URL that can be used by the remote system via a web call back to the originating server who the user is. It might not need to be a full-up implementation of a central authentication system, but along those lines. Just be sure that you're using SSL to encrypt the relevant bits to help avoid man-in-the-middle attacks.
Using Windows Identity Foundation (WIF) you can achieve Single Sign-On.
In WIF, a service called a Security Token Service (STS), issues a token with claims, which can be anything you want to declare about the authenticated user, for instance his roles. In your apps you can use the Page.User, Controller.Page or Thread.Current.Principal properties to check the User claims (though if you'll only be using role claims you can use the IsInRole method for simplicity).
You can easily create a STS using the tools for VS included in WIF's SDK. The Forms authentication will be done in the STS instead of in the Web Forms site and both sites should have a trust relationship with the STS.