IdentityServer newbie here....
I am building a mobile app and would like to provide the end user the ability to sign in using SSO for users that have a corporate identity provider and my company as the identity provider for those that don't have an identity provider.
it's possible that over time we add more external identity providers.
We have an on premise identityServer4 already installed and configured and only using it for client credentials for our API->API communications.
We also have an Azure Active Directory tenant with all of our AD accounts (our internal corporate accounts).
Here is what I would like to do (if possible of course):
Have the mobile app (swift and android, but for now let's just discuss swift) be completely unaware of any external identity providers and have it point to our on-premise identity server for authentication.
Add external identity providers in identity server
Control what external identity providers we "add" all on the backend and not have the UI layer concerned with specific external providers, but have the identity server redirect accordingly.
Not bother the user to have to select which provider to use (if I am a corporate user with an external IDP configured, it should automatically take me to MY e-idp login page, if not then present my own login page)
I am also open to the idea of using Azure identity management as the identity provider and add external identity providers there.
What about Azure B2C?
Can someone please point me in the right direction?
thanks in advance!
You can check this app integrated with AppAuth for iOS. Link in GitHub
Related
We are using the ADFS activity report to migrate our applications to AAD. Everything shows as Ready and when we click on the Ready link, the text says "We've detected on-premises settings for this relying party that can be migrated to a new Azure AD enterprise application. We'll map the fields and create the new application, but users won't be redirected to it until you say so." By the last statement, it seems like the application is automatically created now. Is that the case? If so, how long does it take to create the application and does it keep the same name as in ADFS?
• The message that you encountered “We've detected on-premises settings for this relying party that can be migrated to a new Azure AD enterprise application. We'll map the fields and create the new application, but users won't be redirected to it until you say so.” Means that the application is a SaaS application available in Enterprise application gallery in Azure AD. This does not in anyway mean that the application has been created automatically, it just means that the application is ready to be migrated to Azure AD and is fully available as a SaaS application in Azure AD gallery and doesn’t need any further relying party configuration migration from the on-premises ADFS server.
• Since the message is displayed only for SaaS apps readily available in Azure AD gallery and are equally configured as a relying party trust in ADFS, its configuration information is readily migrated through the ADFS Connect health application to Azure AD and it can be configured in the cloud itself with admin account access needed for the SaaS application’s account for SSO and SAML authentication configuration required through Azure AD.
You can find the image below for your reference, it shows the ‘Dropbox’ application as ready for migration from ADFS to Azure AD: -
Through the above option enabled, you can easily configure your application’s SSO configuration in Azure AD. If all the configurations are up and running, it will happen instantaneously within a few minutes of time.
Kindly refer to this link for more information on migrating federated apps from ADFS to Azure AD: -
https://github.com/AzureAD/Deployment-Plans/tree/master/ADFS%20to%20AzureAD%20App%20Migration
I think the report is still in preview and it is missing a create application button.
All the documentation only shows the reports & not the create process.
Also this migration tool, is a repackage of the powershell test commands:
https://github.com/AzureAD/Deployment-Plans/tree/master/ADFS%20to%20AzureAD%20App%20Migration
So I assume you need to create the application manually based on the report.
We have several apps which are built using .NET are running in VMS(on-prem)
All apps will be registered to Azure AD.
Can we use user managed identity to access key vault form these on-prem apps
Thanks in advance
No, you cannot use a Managed Identity from on-prem apps.
[...] a managed identity is a service principal of a special type that may only be used with Azure resources.
Source: What are managed identities for Azure resources?
To see a list of resources currently supported, see Services that support managed identities for Azure resources.
You can, however, use a Service Principal to connect to Key Vault from an application running on-premises.
To do so, Use the portal to create an Azure AD application and service principal that can access resources.
For Service Principals, authentication can be done in two different ways: password-based authentication (application secret) and certificate-based authentication. Using a certificate is recommended, but you can also create an application secret.
To access resources that are secured by an Azure AD tenant, the entity that requires access must be represented by a security principal. This requirement is true for both users (user principal) and applications (service principal). The security principal defines the access policy and permissions for the user/application in the Azure AD tenant. This enables core features such as authentication of the user/application during sign-in, and authorization during resource access.
If you cannot use managed identity, you instead register the application with your Azure AD tenant, as described on Quickstart: Register an application with the Azure identity platform. Registration also creates a second application object that identifies the app across all tenants.
We have G Suite as an identity provider in our company. Some of users also use Azure and Office 365. We want to be able to login by using Google account to Azure Ad and later have this account in AD and assign roles and groups in AD and whole Azure. We want to change passwords in Google etc.
How to setup SSO from Google to Azure?
Azure AD supports the concept of Identity Providers for External Identities. You can read about it here on Microsoft Docs.
You could enable users from identity providers like :
Google
Facebook
Direct federation (to external identity providers that support SAML or WS-Fed protocols)
Since you specifically mention G suite as an identity provider in your company, Direct federation may be the most relevant one for you. I say this because using Google federation directly is designed for Gmail accounts as mentioned in the note here on Microsoft Docs
How to setup Direct Federation is explained in detail here on Microsoft Docs
Please note that
This feature is currently in Preview
There some important limitations in terms of domain requirements and authentication URL as stated here on Microsoft Docs
From Azure API Management developer portal, Can we create client id and secret automatically while each user creates application?
Basically i need to set up my AD tenant/B2C Tenant and while application creation happens from API Manangement development portal, Development portal should automatically/programmatically call to my configured AD tenant/B2C tenant and should create Application inside AD/B2C, the created application's client id and secret should be written.
Is this feature supported in Azure APIM developer portal or please suggest best away to achieve inside APIM developer portal.
Thanks in advance.
Vetrivel
Please note as informed in MSDN thread, as of now you may not be able to do it directly through Azure API Management. You can go ahead to log a feedback request here - http://aka.ms/apimwish.
For now, you can create separate application that would call both API Management API and AD API to setup required applications.
We are using IdentityServer4. We have a Windows 2016 server running ADFS (Active Directory Federation Services) version 4.0. This version of ADFS has OpenID Connect endpoints to do active directory authentication. We set this up as an external oidc provider in IdentityServer4. The authentication works fine. What I'm having an issue with is the logout. The current logout correctly disposes of the identity server and client cookies, but doesn't log the user out of the external provider (ADFS). I upgraded the ADFS server so the metadata endpoint exposes end_session_endpoint, frontchannel_logout_supported, and frontchannel_logout_session_supported properties.
What is the proper way to have our identityserver4 implementation also ask the external provider to perform a logout when it does? I'm a little confused by the spec.
http://docs.identityserver.io/en/release/topics/signout_external_providers.html
http://docs.identityserver.io/en/release/topics/signout.html#refsignout
I'm not sure if the front-channel or back-channel is what I should be looking at in this scenario or if this is even related. The spec also mentions a idp value at authentication time that would indicate to the identity server that a external provider needs a logout as well. Is this what I should be looking at? Little lost. Looking for guidance. Thanks!