Is there an elegant way to use a single set of ADB2C IEF custom policies across multiple environments (eg dev/test/prod)?
This issue has arisen as we have designed two custom IEF policies - one for signin, and separately one for signup
On the signin page ADB2C tries to generate a url for signup, but because we have a custom policy for signup we need to rewrite this URL in javascript so that it points to a different url
(as described in these q/a's) :
B2C - How to override sign up now link (custom policy)
Msal 2.0 - how to generate Sign Up link with Azure B2C?
But now we start hitting more issues. We can't rewrite the url to myapp.com/signup, because we need to rewrite it based on the environment. It needs to rewrite to dev-app.com/signup or test-app.com/signup etc
So the only way I can see to fix this is to use separate ContentDefinitions for each environment, each with customised javascript.
But then I also need individual policies for each environment so that each policy can use a specific content definition file!
Ugh. Is there an easier way than trying to maintain what should really be one set of policies across three sets of environments (which ends up becoming 6 sets of policies, content definition files etc)?!
Fantasising a bit - I think ideally we'd configure MSAL to send the environment to the policy somehow, and then at least make that variable available in the policy files so that they could perhaps fetch the content definition files with a query parameter?
<ContentDefinition Id="api.signin">
<LoadUri>https://storage.com/adb2c/signin-{Culture:RFC5646}.html?env={environment}</LoadUri>
Yes, use DevOps and Azure Pipelines.
You can then search and replace the variables that you need to change across environments.
Related
I would like to show Identity providers dynamically based on the tenant[ i.e OIDC domain_hint] during the Azure B2C Sign In user journey. I have referred several examples on custom policies, however unable to find a way to display/hide an IdP based on tenant. I was able to use this good example to do Home Realm discovery in custom policy using an Azure Function, but it doesn't show 'list of IdP' applicable for the tenant/domain. Other SO questions, that came close to this but didn't answer are 1, 2. Even if I serve custom HTML file from blob storage, how to show only certain Identity providers and hide some based on the tenant/domain_hint ?
Depending on the number of domains/tenants permutations, you could put that logic on the application side to execute different PolicyID's. This is assuming the number is low therefore it would be a policyID : IdPs mapping.
This is a bad solution if you have a HIGH volume of hints.
Alternatively, you could perform an API call via JavaScript to delegate populating the list of Identity Providers. Then, it would execute another self-assertive page that would trigger that specific identity provider. The flow would look like:
App (passes domain hint)--> B2C login page (JavaScript REST API on page and request list of IdP's based on previous domain hint) --> 2nd Self-assertive page (value passed from first page to initiative the correct IdP) --> IdP pages load.
You can adjust the logic in different ways to meet your needs.
You could store the tenant in a claim using claim resolvers, then have an orchestration step for each possible combination of IdPs you want and use preconditions on those steps to only execute them depending on the tenant. Hopefully that works.
I'm using Github Actions to build some Docker images that I want to push to Azure Container Registry. I am attempting to use OIDC as an auth mechanism, based on this GH Action. I know the action supports other auth strategies, which I have discarded for my use case for reasons.
According to GH docs the "subject" field needs to be populated based on the GH account, repo name and branch name. However, want to build Docker images for multiple branches, which seems to require one federation config per branch - not practical, IMO.
So my question is: does anyone know if it's possible (and how) to set up a single federation config with a "subject" value that would work as a wildcard of sorts, covering all branches from a give repo?
thanks!
On AWS it is possible to use wildcards, like:
"repo:MY_ORG/MY_REPO:*"
but that doesn't seem to work on Azure, you can enter a wildcard in Azure Federated Credentials, but the GitHub workflow fails. To actually need a branch is crazy, as we'd need to setup new credential config for each new git branch.
I worked around the issue by using GitHub environments. I set an environment (called main but it can be called anything) and then set my workflow like this:
jobs:
test:
runs-on: ubuntu-latest
environment: main
and then in Azure set the federated creds to use:
Entity of Environment rather than Entity of Branch
This will then work for any branch - but clearly if you use GitHub environments for other reasons this may not be viable.
Note that, since Oct. 2022:
GitHub Actions:OpenID Connect support enhanced to enable secure cloud deployments at scale (Oct. 2022)
OpenID Connect (OIDC) support in GitHub Actions enables secure cloud deployments using short-lived tokens that are automatically rotated for each deployment.
You can now use the enhanced OIDC support to configure the subject claim format within the OIDC tokens, by defining a customization template at either org or repo levels.
Once the configuration is completed, the new OIDC tokens generated during each deployment will follow the custom format.
This enables organization & repository admins to standardize OIDC configuration across their cloud deployment workflows that suits their compliance & security needs.
Learn more about Security hardening your GitHub Workflows using OpenID Connect.
That means, from the documentation:
Customizing the subject claims for an organization or repository
To help improve security, compliance, and standardization, you can customize the standard claims to suit your required access conditions.
If your cloud provider supports conditions on subject claims, you can create a condition that checks whether the sub value matches the path of the reusable workflow, such as "job_workflow_ref: "octo-org/octo-automation/.github/workflows/oidc.yml#refs/heads/main"".
The exact format will vary depending on your cloud provider's OIDC configuration. To configure the matching condition on GitHub, you can can use the REST API to require that the sub claim must always include a specific custom claim, such as job_workflow_ref.
You can use the OIDC REST API to apply a customization template for the OIDC subject claim; for example, you can require that the sub claim within the OIDC token must always include a specific custom claim, such as job_workflow_ref.
Is it any other way to get assigned platforms to application in AADB2C except following?
https://graph.microsoft.com/v1.0/myorganization/applications?$filter=appId eq 'guid id'
If I add multiple platforms like IOS/Desktop/Android all redirects uris for them land in the same b2c applications property publicClient: redirectUris[] I need to know which uri is for which platform type and I do not want to achieve this by guessing based on specific redirect uri structure.
You can either write your own logic to determine which redirect Uri belongs to which app. Or another cleaner alternative is to have multiple apps, one per platform. There is no additional cost to having a separate app per platform each with a single redirect Uri. And that may give you additional flexibility to support different auth flows or configuration in case of library updates or changes.
I have custom policies for sign up, sign in and reset password. All with custom ui.
I want to have different CSS styles and show different elements for different webs that use the sign up policy. Should I create different sign up policies with different custom UIs to accomplish this?
Also, I want to change the position of the UI fragments embedded by Azure B2C. Is css the only way to change this?
If you are using base b2c policies, then the only way is to create multiple sign-up/in policies. But please keep in mind that there's a limit to number of policies you can have in your b2c tenant (currently 100 policies). So if you want to do that also for reset password or any other user journey you will hit that really fast.
So... looking at the tags I can see Identity Experiance Framework, in that case you can use sample provided by MS - active-directory-b2c-ui-customization-custom-dynamic and change your UI based on the additional query parameter that is being sent to policy.
As for moving embedded elements inside your <div id="api"></div> CSS is the standard way. But you can look at the b2clogin.com program that is currently in public preview but it is not recommended to be used for any production use.
I wonder if there is a way to add within the Application manifest file (or any other way) to have two (more) "targets" share the same Application ID.
If I register a new app - the appID is new.
Problem is that we have one solution that is configured for SSO but it runs on two domains - for managing languages (as what you see and can do depends on where you log in).
We have somedomain.xa for language XA and somedomain.yz for language YZ. But there are certain URL arguments that *** up the situation as
somedomain.xa --> rewrite --> somedomain.xa/companyID=100&lang=xa
somedomain.yz --> rewrite --> somedomain.yz/companyID=100&lang=xa
And the registration inside the solution is to use company ID, find the AppID from a DB table and then perform the handshake and authentication process. And if I register both domains on same ID, the SSO solution throws error.
Thus my "problem" - of there is a way out?
From your description, it looks like you have one registered application (one Application Id) that runs under the context of one Azure AD tenant, and you want to use this one application to redirect use to either one of the two different domains you have - is this correct?
If this is the case, what you need to do is just configure multiple redirect URLs for this one Application Registration information in portal.azure.com - https://somedomain.xa/page and https://somedomain.xa/page - then use set the Redirect URL parameter when requesting the authentication challenge - in your case as you detect user's language.