I am trying to configure Azure AD (IDP) integration with Gigya (SP) for individual Gigya sites.
I have configured an Azure AD enterprise application and the following configuration is required:
Identifier (Entity ID)
Reply URL
Sign on URL
Could anyone confirm whether the Sign on URL is a Gigya URL and if so what this might look like?
The Sign on URL is just http://companyname.gigya.com since it's just your company site on Gigya. You can get the actual values by contacting the Gigya client support team.
You can also check this by going to Azure portal > Gigya application integration page > single sign-on > Select a Single sign-on method > SAML/WS-Fed > Set up Single Sign-On with SAML > Edit > Basic SAML configuration.
Check out the documentation:
https://github.com/uglide/azure-content/blob/master/articles/active-directory/active-directory-saas-gigya-tutorial.md
https://learn.microsoft.com/en-us/azure/active-directory/saas-apps/gigya-tutorial
Related
I am working in a project where we are authenticating any REST API requests from UI or anywhere else using ADFS STS tokens. There are some direct calls from UI with ADFS STS token in header for authentication/authorization and there are some external 3rd party calls not from UI, but also using ADFS STS tokens in header. Now we are planning to migrate partially to Azure AD token, post which there may still be some applications that will keep using ADFS STS tokens, so there can be situation where an external application that is unaware of migration to Azure may still call an internal application using ADFS STS Token and we are supposed to be compatible with it. Similarly there can be a situation that an internal application that is migrated to Azure AD token is internally calling one of the legacy applications which is still not migrated to Azure AD and won't in future too.
I have two challenges now:
How to support the above design so that even if an Azure token is used the API is still able to call an external service (working on ADFS) by creating an ADFS token from within the code and setting it in headers ?
Header in a HTTP request seems to be an unmodifiable data and when i tried to modify it within a requesttemplate in an request interceptor code, it failed saying unmodifiable map.
How do I handle this ? Please someone help.
Unfortunately I cannot share code due to internal restrictions.
Please check if below references provide some idea in your case.
According to Mix ADFS and Azure AD for authentication - Microsoft Q&A.
If you have O365 federated with ADFS and you federate an application
with Azure AD, the authentication flow would be:
User accesses the application which is federated to Azure AD.
Application will redirect to Azure AD authentication endpoint (https://login.microsoftonline.com) for authentication.
User will be prompted for credentials.
Based on the UPN suffix (If the domain is federated with ADFS), user will be redirected to ADFS.
ADFS will authenticate the user and issue a WS-Fed token to Azure AD.
Azure AD will receive the token and issue a SAML token to the application.
User will finally get access to application.
References:
Configure AD FS 2016 and Azure MFA | Microsoft Docs
Azure AD Connect - Manage AD FS trust with Azure AD using Azure AD
Connect | Microsoft Docs
federating ADFS with Azure Active Directory (techdirectarchive.com) & reference- Solution Zone
We have single page app (Angular front end and .NET Core Web API) using Azure AD for authentication. Both front end and and Web API are registered in the same tenant and WebUI has permissions to call the Web API. This Web API uses a few other internal Web API's as well.
We have a new requirement in the app to allow access to certain areas of the app to external users who need to register first. So now the app need to authenticate both existing AD Users plus external users.
My question is if this is possible in a single application? And if yes what is the recommended approach for authenticating both corporate and external users?
As you need to use register feature, you will need to use Azure AD B2C, and it supports multi providers for a valid user flow.
For example, if you want azure ad users and external users to use your application. You can choose OpenID Connect(Azure AD) and Local Account(or other social accounts). In the login page, users can choose to sign up or use Azure AD account to login directly.
Steps:
Just keep your Wep Apps and api apps in the existing tenant. You need to create a Azure AD B2C tenant, create a user sign up/in flow, configure the providers for the user flow.
Reference:
Create B2C tenant
Create user flow
Add identity providers
Configure your original Azure AD application to the identity provider
I'm trying to configure the Microsoft Portal add-on for Dynamics 365 to work with an external identity provider that supports SAML2.
I've followed all the steps as described in the documentation: https://learn.microsoft.com/en-us/dynamics365/customer-engagement/portals/configure-saml2-settings
The portal is correctly redirecting me to the identity provider login screen, I enter my credentials and then I am redirected to the URL specified in the AssertionConsumerServiceUrl site setting, which should be: https://mycustomportal.microsoftcrmportals.com/signin-saml2
At this point, we get a 404 and we do not get logged in.
I tried setting up the SAML2 Azure AD settings which take us to a different endpoint (https://mycustomportal.microsoftcrmportals.com/signin-azure-ad) and it works as expected.
Has anyone had any luck in getting the generic SAML2 sign in working?
I have setup Single Sign-On with SAML in Azure portal but now I don't know how to do in VB codes. I need guidance on how to do in visual studio so that once I publish the web to cloud it can call SAML/Azure AD and redirect to login Microsoft and if login success will redirect to webapp.
Thank you so much for the help
Registering your app is just a way for Azure AD to know that your app wants to authenticate its users with AAD.
In your application, you will use one of the many SAML SDKs to integrate AAD authentication.
I have an ASP.NET Core Web API app and to secure it, I've implemented JWT Bearer authentication. The next step is managing user access and issuingJWT token.
Initially I considered using Azure AD B2C but it doesn't seem to support my business requirements. So I'm now considering using Identity Server 4.
Is Identity Server 4 run as a completely separate application? Also, am I understanding it correctly that it is used as:
A web interface for users to register and login
Also a web app with API that issues the JWT token
In other words, does Identity Server 4 "act" as my own Azure AD B2C service?
IdentityServer 4 is a Web app (Login & Logout pages) with an API that implements the OAuth 2.0 and OpenID Connect specifications. The samples provide a simple user login and logout views that you can change to your liking.
Regarding the user registration process, you may add that to your IdentityServer4 implementation or have that as a separate web application.
Similarities to Azure AD B2C
This came from another blog article
Authorization
Azure AD B2C allows you to model user roles as membership in groups
that you define. You can’t currently get a token containing those
claims, but you can use the Azure AD Graph API as a workaround to
retrieve the group memberships, and use them in authorization checks
inside your application. It’s a little tricky right now, but
improvements to this are on the B2C team’s roadmap.
API Authentication
Azure AD B2C can provide tokens for authenticating API access via
OpenID Connect, but beyond that the functionality is limited. The
OAuth 2.0 Client Credentials flow isn’t supported, and B2C doesn’t
include any API key management features, so you’ll need to roll your
own code if your services need to support API key authentication.
Another article with PROS for IdentityServer4.
IdentityServer 4 is an authentication framework capable of out of the
box Single Sign On (SSO) and security for your APIs, and most recently
support for implementing your own authentication protocols and tokens,
with a sample implementation for the WS-Federation protocol and SAML
tokens. SSO works across all applications regardless of whether they
are using OpenID Connect or WS-Federation.
Summary
IdentityServer4 is similar to Azure AD B2C with more functionality as noted in the linked articles.