In digital world, end-users have unspecified number of apps in their personal life as well as professional. In large enterprises, IT team doesn’t know the exact count of applications used by their organization. If counting or remembering the name of the application is quite challenging, you just imagine how someone can remember the URLs and credentials of these applications.

To simplify it, Microsoft has web based access panel called My Apps for enterprise/social applications. You can publish cloud apps available in enterprise gallery or on-premises apps through application proxy or both together seamlessly using a single access control panel. This access panel is not only meant for accessing applications but at the same time it provides few self-service capabilities as well. It also makes sure that security is not compromised at all in any scenario by using capabilities such as Multi-Factor Authentication (if enabled).

Default url of this web-based portal is https://myapps.microsoft.com but can be customized with your specific domain such as https://myapps.microsoft.com/<youscustomdomain>.com . Though, it looks attractive and ease your life but it has following dependency:

1. It needs Azure AD (native or synced identity)
2. Cloud applications need to be published through Enterprise gallery
3. On-premises applications need to be published through application proxy.

Look and feel of myapps:

Scenario 1: Let see how does it look for a user who doesn’t has anything published.

Scenario 2: Let see how does it look for a user who has published apps.

Look and feel of self-service feature in myapps:

Note: You can see few options here (Change password, Set up self service password reset and Additional security verification), it is because of self-service password configuration for this user in his organization. You may not see this options if it is not configured in your environment.

Different applications may have different set “single sign-on mode” methods for authentication and authorization and every method has different configuration. Here is a list of single sign-on modes that cover most of the options:

Azure AD single sign-on disabled

Single sign-on disabled means that you do not want this application to be integrated into Azure Active Directory for single sign-on. This means that when a user signs in to the application, that user must manually enter their username and password. If you had previously enabled an application for Azure Active Directory single sign-on integration and then change back to the single sign-on disabled mode, this will result in users needing to enter their username and password every time they launch this application.

SAML-based Sign-on

Federated single sign-on enables rich and secure authentication to applications using the SAML protocol. Follow the steps below to connect Salesforce to Azure AD using SAML.

Password-based Sign-on

Password-based single sign-on enables secure application password storage and replay using a web browser extension or mobile app. This leverages the existing sign-in process provided by the application, but enables an administrator to manage the passwords and does not require the user to know the password.

Linked Sign-on

Linked sign-on allows you to add a link to an application in the Azure Active Directory Access Panel and/or Office 365 application launcher for selected users. This option does not add single sign-on to the application, however the application may already have single sign-on implemented using another service such as Active Directory Federation Services.

Integrated Windows Authentication

Integrated Windows Authentication (IWA) provides a single sign on experience by allowing the Application Proxy Connectors permission in Active Directory to impersonate users to the published application, using Kerberos constrained delegation.

Header-based Sign-on

Microsoft and Ping Identity have partnered to extend Azure AD Application Proxy to support single sign-on (SSO) for header-based authentication to web applications running on-premises.

Note: These are sign-on methods and few of them need additional configuration based on application. Therefore, please make sure that you have all required information to configure any one of these sign-on methods.

Web browser requirements: Browser used to access myapps application should have minimum JavaScript and CSS enabled. Following browsers are supported for myapps:

Edge on Windows 10 Anniversary Edition or later

Chrome — on Windows 7 or later, and on MacOS X or later

Firefox 26.0 or later — on Windows XP SP2 or later, and on Mac OS X 10.6 or later

Internet Explorer 8, 9, 10, 11 — on Windows 7 or later (limited support)

Extension required for my apps secure sign-in: You need to install an extension to use my apps secure sign-in. Make sure you are not trying to install it in incognito window or private mode.

Mobile Apps for Android and iOS: My apps is also available through mobile app. You can use it either on android device or an iOS device

Min Android version: 4.1 and above

Min iOS version: 7 and above