The Microsoft docs state that
To sell Office Add-ins to organizations, you need to create a licensing database. This is necessary because:
...
Centralized deployment does not allow users to buy add-ins from AppSource and deploy them. AppSource paid add-ins today only work with personal identities (Microsoft accounts), not work or school accounts.
So, if I want an organization to adopt my Office Add-in I have to handle the licensing workflow myself. This raises a few questions that the docs don't answer.
An organizational user will not have an AppSource (AS) token. Instead, how do I authenticate an org user if the user is not logged in to Office? My add-in should implement a log on screen or single sign-on (SSO)? How do you log a Microsoft user on without single sign-on? They input their username/password and I send this to Microsoft Graph? That doesn't sound secure at all (the fact that I have their Office credentials, that is).
I guess I'm confused about the authentication and authorization workflow of an add-in that is intended for organizational license. Can anyone point me to a working example or provide more information, please?
You seem to have multiple, related questions. I don't know if this will answer them all.
Users can log into Office with either a Microsoft Account or a work-or-school account. There is a single sign-on system, that is currently in preview, that enables you to leverage this same sign-on credential (including a work-or-school credential) for your application. For an overview of the system, see SSO in Office Add-ins.
Like any web application, you could also of course, implement your own backend user tables with user names, encrypted passwords, user permissions, and license status.
Finally, your web application could leverage one of the social identity providers such as Facebook or Microsoft Account. In the case of Microsoft Account, if you don't use the SSO system, then users would have to login to the MS account a second time, even if they are already logged into Office with that account.
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 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
I'm working on a project for an education institution and we currently have live#edu set up with the SSO Toolkit 4.5. We have a portal (home grown) that our users log in to using their AD credentials (local AD only) and then we wire up the certificate to pass up to live#edu so they're not prompted again for login creds when they view their MS mail.
MS is going to stop support for this methodology at the end of the year and so we're now in the process of upgrading our environment to work with Office 365 education. As such, we have set up and ADFS with an Azure AD but I'm struggling getting a process in place where our users still only need to enter their login credentials once on our portal (which is externally facing) and then providing them with a token that will persist on their trip to Office 365. Right now it works as follows: users go to portal.microsoftonline.com and enter their email address. When they tab out of that field, MS checks and finds our domain so then redirects the user back to a login page for our ADFS solution. At this point, users are required to log in again (if they're not already logged in) or they're taken to the MS offerings.
Bottom line, instead of making a "single" sign on solution, they've added more places that our users need to provide their credentials (or just username (email address)).
I'm wondering if there's a solution we can provide to our users similar to the SSO Toolkit 4.5 way of doing things where we can authenticate our users only once on our portal, then provide them access to the O365 services?
I'm not an infrastructure guy at all so I may have provided some misinformation above as to how we have things set up. What I do know from our current implementation is that we need to use "WS-Federation".
I'm wondering if a SAML approach would solve the issue I've described above and let us just challenge for credentials once on our portal page.
any ideas or suggestions would be greatly appreciated.
TIA
This is indeed possible. Read about AzureAD access panel (http://blogs.technet.com/b/ad/archive/2014/10/30/customize-your-app-sso-experience-with-azure-ad.aspx)
1) User will navigtate to https://myapps.microsoft.com/{your_school_domain_name.edu} 2) they will be directly redirected to your ADFS server for signin 3) once they signin they will see the list of apps assigned to them (including O365 apps) 4) click on OWA/SharePoint icon and navigate to the app without having to sign in again.
If you quickly want to test 1) and 2) open an in-private/cognito browser and navigate to https://myapps.microsoft.com/microsoft.com - you will not see O365 or Azure AD signing page - instead you'll be taken directly to the MSIT ADFS signin page.
Hope this helps.
I'm working in a company that uses Microsoft Active Directory. We have an external company that provides an internal web site for a particular project. The site is external to the company. The sign on to the external site is the user's company email.
We want a system whereby the external site calls into the organisation's AD to verify if an email address is still valid or if the user has left the company. It should be a simple call to Active Directory Federation Services or some sort of SAML interface. The call would be a simple request 'here's an email, is it valid?' and the response is either yes or no.
Our IT department are trying to tell us that it's too complicated and I don't believe them. I think they just don't want to do it.
Does anyone know how easy it would be to create a simple system that would allow an external service to do the query outlined above.
ADFS is not meant to do that. However, a by-product of using it, would be the validation you are looking for.
The first question would be: what is the authentication method of your app? e-mail and what else? password? which password? Does the app keep a database of users/passwords?
ADFS works as an "identity provider" and would authenticate users in AD. ADFS would supply a security token that can be consumed by your app. Part of the information sent in the security token could very well be (and often is) the user e-mail address (that's why it is a "by-product").
For this to work, the app would have to be changed to accept security tokens (SAML tokens to be specific). If the app is .NET based, then it is done usually with WIF (WIndows Identity Foundation).
This approach would be the most elegant and secure because the app would delegate the responsibility of authenticating users to the authority of these employees: AD.
App --trusts--> ADFS --authenticates--> AD
Setting up ADFS, etc is not super-difficult, but it is not super-simple either, and might not be worth just for this app. There are other lighter weight alternatives: open source products like Identity Server, or products like the one I work on.
Now, if all you need to do is to validate that the e-mail actually exists, the best is to send a verification message to that address with some unique code that the user sends back. This is the same approach used in many common web apps.
Agree with everything #Eugenio said - have same questions about authentication.
But if you simply want code to query an user's email address in AD, you use the AD API's.
I am in the process of scoping out whats involved in setting up single sign on using SAML and ADFS. A query has come back that I can't answer and can't seem to find anywhere.
Is it possible to carry out the usual user profile actions via ADFS? For example :
Can I register new users via ADFS?
Can I provide forgotten password / reset password functionality via ADFS?
I'm getting confused and have a feeling I am barking up the wrong tree!
No, AD FS only delivers security tokens for Active Directory accounts, after providing some form of credentials for such an account. It does not make any kind of changes in Active Directory, nor anywhere else.
No, AD FS has no 'reset password' functionality. However, the AD FS sign-in pages can be customized, and the functionality to change the (AD) password can be added by customizing/creating the appropriate ASP.NET pages. Been there, done that. Unfortunately I cannot share that code.
(This answer applies to AD FS 2.0 only; I'm not sure about AD FS 1.0.)
#Marnix is correct - ADFS is an "Access Manager" not an "Identity Manager".
As you can customise pages, there is nothing stopping you creating provisioning pages or adding links to a provisioning system.
Word to the wise: The "standard" ASP.NET membership pages provision to a SQL DB which won't help you. ADFS authenticates against AD only. You need to use AD membership.
Also, for internal users who login to their desktop with WIA and SSO behind the scenes with ADFS, you get the standard password functionality e.g. password about to expire, change password etc.
In addition to that: Microsoft has another product which integrates with ADFS (and other auth mechanisms) called Forefront Identity Manager which provides password reset / user self management as well as account creation via delegated fine granted rights. All that using a web-interface.
i guess that is what you're looking for.
However: adfs itself is only a tool to provide federation and SSO - so it's there for authentication / delegation, not mangement.