Just getting started with a migration of an existing legacy (local database) IDP to Azure B2C. I want to use something similar to the seamless user migration ( https://github.com/azure-ad-b2c/user-migration/tree/master/seamless-account-migration/policy ) custom policy. Looking at the B2C community GitHub repository, it is missing the base policies. Any idea where I can find those base policy examples?
The pre requisites are here:
https://learn.microsoft.com/en-us/azure/active-directory-b2c/custom-policy-get-started
Or use my tool to automate it: https://aka.ms/iefsetup
Related
Is someone already configure Google Workspace working with Snowflake and has user automatically created (as Okta can purpose)
Thanks for the help
If GSuite support SCIM, Then One thing that you may try is Custom SCIM integration as suggested here- https://docs.snowflake.com/en/user-guide/scim-custom.html
Currently, Custom SCIM integrations are supported for identity providers that are neither Okta nor Microsoft Azure AD.
Although I've not tested this with Gsuite, you may give it a try provided Gsuite has support for SCIM.
Google Workspace supports SCIM autoprovisioning on SAML apps that are already part of their Pre-integrated SAML apps catalog, although this is not explicitly mentioned in their documentation, Automated user provisioning is available only for Supported apps:
See About automated user provisioning
Snowflake would need to work with Google Workspace to see if their solution could be added to the catalog.
I have a dotnet 5 Blazor Server-Side website deployed to Azure App Service. I've followed the tutorial at https://learn.microsoft.com/en-us/azure/app-service/scenario-secure-app-authentication-app-service to provide Authentication. Now, any attempt to reach my site requires a login from a user of the Azure AD.
Unfortunately, I haven't been able to find any guidance on how to manage Authorization though. For example, I'd like to restrict access to pages to members of specific groups within the Azure AD. I seem to remember years ago, there was some kind of membership provider database that the site would check.
The kind of thing I'm looking for is to be able to decorate the razor page with the name of an Azure AD group of which anyone attempting to load the page must be a member. Does anyone know of a link that describes the "official" way to achieve this?
Role-based access control (RBAC) a way to authorize applications based on the role permissions granted by the administrator to individual users/groups. Please refer this link for the detailed documentation on how to create/manage roles for an application in Azure AD.
Please refer this link for more details on how you can access the razor pages base on the roles assigned to the users/groups.
I am currently looking to connect ADFS with GLPI or Centreon , but I found that I can't because these two apps don't use SAML .
I am now focused on how can I connect GLPI or Centreon to Azure AD using Application Proxy to authenticate with tenant Azure AD account.
But after configuration I can't log in to the application itself ..
my main question is of GLPI or centreon are planned to work with Azure AD.
Has someone has worked on this kind of project? It will help me out to have more info.
Centreon doesn't manage Azure AD so far.
No enhancement is visible in the roadmap for this.
However, Centreon supports LemonLDAP::NG as a frontal.
There are 2 plugins available for GLPI that enable SAML authentication.
https://plugins.glpi-project.org/#/plugin/fpsaml
https://plugins.glpi-project.org/#/plugin/phpsaml
I struggled with fpsaml, the configuration was overly complex and required editing configuration files that could be overwritten IIRC. The plugin has not been updated in some time and it was last compatible with GLPI 9.1.3.
I ended up writing the phpsaml plugin using the Onelogin SAML Toolkit. Using phpsaml you can configure all SAML settings from the plugin configuration page. It is compatible up to GLPI 9.6.
You can find more info on github at
https://github.com/derricksmith/phpsaml.
I don't have previous experience in this kind of projects, but I know SAML is supported by GLPI as external auth.
You'll need to setup your apache (or whatever web server you're using to support it and GLPI config would be quite easy.
I have configured Azure B2C as IDP via SAML successfully for a single Service Provider. There are many pieces that i don't understand in this setup even though its working.
I will describe what i have so far and then ask questions later.
Let's say I have two Service Providers,SP1/SP2 both require SAML and a page to signup/signin. SP1 requires loyality_id as custom attribute and SP2 requires product_name attribute.
Here's the source code that works.
Credit/Thanks to this blog
Below is the high level summary of the configuration.
SAML for SP1 (Service Provider 1):
Add signing and encryption keys to the B2C tenant
Register Identity Experience Framework applications
Create web app IdentityExperienceFramework in Azure Active Directory
Create native app ProxyIdentityExperienceFramework in Azure Active Directory
Start from starter pack for LocalAccounts as base
Add Saml2AssertionIssuer to the base policy
Add user journey SignInSaml to the base policy
In Extension Policy override "Local Account SignIn" claims provider and add substitute values for "client_id" and "IdTokenAudience" from apps that were created earlier
Policy file with RelyingParty for SP1
This describes the output claims that are added to the SAML response
Signup/signin policies for SP1:
Create built-in signup and sigin policy
Create Application in Azure B2C blade
So far with this setup, I have two Applications in Azure Active Directory for custom policies and one Application in Azure B2C blade for built-in policy.
According to https://learn.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-create-custom-attributes-profile-edit-custom,
Extension properties can only be registered on an Application object
even though they may contain data for a User. The property is attached
to the application. The Application object must be granted write
access to register an extension property.
What is the "Application" the above paragraph is referring to?
What is the purpose of the apps IdentityExperienceFramework/ProxyIdentityExperienceFramework
To setup for SP2, do I need to create separate Azure Active directory apps for IdentityExperienceFramework/ProxyIdentityExperienceFramework? Or can I use the same ones? How do custom attributes factor in this?
How do I setup custom attributes in this case where SAML is through Custom policy and Signin/Signup is builtin policy
In this case, under what App context are the custom attributes created?
I appreciate any pointers.
Thanks
The application is the one created in the section "Creating a new application to store the extension properties".
The apps purpose is to enable sign-in using local accounts. The same apps can be used accross multiple policies.
Custom attributes are related to the application created in app registrations at Azure AD level, and with the permissions detailed in the configuration docs.
In my Github profile, you can find a different implementation of the B2C as SAML issuer scenario: https://github.com/marcelodiiorio/My-Azure-AD-B2C-use-cases.
Tell me if you have more questions.
I am developing a office add-in.
This office Add-In is supposed to retrieve the term store from SharePoint.
By following this tutorial:
https://learn.microsoft.com/en-us/office/dev/add-ins/develop/create-sso-office-add-ins-aspnet
I managed to get an access token to be used for Graph api. However the Graph does not expose any way of getting the term store. Is there a way we can generate an access token to be used with SharePoint and maintain the SSO?
It might be possible by registering an Azure AD v1 app but I could not find any documentation describing that.
I have a similar requirement, but in my research I wasn't able to find a good solution for this scenario.
I think it is probably possible to use a provider hosted SharePoint add-in. And then use the Authorization Code flow for obtaining an access token. Since the SharePoint add-in is trusted it will not require user login.
Of course this does mean the add-in needs to be deployed in SharePoint. If your Office add-in is distributed through the store this isn't really a great solution.
Hopefully there are other ways of achieving the same.
You could call SharePoint Online APIs (via REST or CSOM) with Azure Active Directory Apps. To call APIs secured by Azure AD, your app must acquire an access token from Azure Active Directory.
Please first refer to this document for integrating applications with Azure Active Directory. Then use Azure Active Directory Authentication Library (ADAL) to easily authenticate users to cloud or on-premises Active Directory (AD), and obtain access tokens for securing API calls.