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.
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.
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.
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.
We have an application that we want to host only once but allow 2 different domains to direct to the one instance then we change the branding based on the incoming host. For instance https://app.abc.com points the same instance as https://app.def.com.
So they are not subdomains but rather independent domains. This would mean they also share the same Azure registered application but different return url's https://app.abc.com/auth/openid/return and https://app.def.com/auth/openid/return.
The Azure portal, however, gives the error
"You may not use more than 1 external domain(s)"
.
Is there any way around this without having to host 2 instances of the same application, each with the own Azure application/client id?
As Wayne mentioned, it is not currently possible to reply to multiple domains.
However, one workaround is to build a proxy in one of the websites. You always redirect to this proxy, which then redirects to the proper site. You could use the state parameter to store which "site" the user clicked "sign in" from, and then based on that redirect properly. You would have to be careful in making sure the token is passed through securely.
Unfortunately, you cannot achieve this.
Reply URLs must all belong to the same domain. And Redirect URIs must all belong to the same domain .This is a limitation for AAD B2C application Registration.
You can also see this note in Azure portal:
Is there any way around this without having to host 2 instances of the
same application, each with the own Azure application/client id?
For Web API or Web App, as I known, there is no way to achieve this for now.
I suggest you can upvote this idea in this Uservoice Page, AAD B2C Team will review it.
Hope this helps!
In case anyone stumbles across this issue as I did today, I found a workaround for this.
Caution: This method is not officially supported by MS according to a warning from MS in the Azure portal (see the second screenshot)
1) In your B2C tenant, navigate "All services --> search for "App registrations" --> click "App Registrations"
All services --> App registrations screenshot
2) Find your application in the application list and click on it. Note the warning from MS (see screenshot)
App registration list screenshot
3) Click on "Authentication" and add your Redirect URIs to the list. This is the same UI as non-B2C tenants.
Redirect URI list screenshot
It allowed me to enter redirect URIs with different domains. It doesn't appear to have the limitation as the "Azure AD B2C" blade. I had to wait a minute for the change to propagate, but it worked for me. I'm not going live with this anytime soon, so I'm ok with doing this for now. When I do decide to go live I'll probably find some other way of doing what I want if MS still hasn't green-lit this method.
Again, MS warns against using this at the moment, but hopefully they'll officially support it soon.
What Cross-Domain Single Sign-On implementation best solves my problem?
I have two domains (xy.com & yz.com) which already have their own database of users and are already implementing their user authentications separately. Recently there has been the need to implement CDSSO so that users dont have to log in each time they try to access resources from both domains.
Ideally the CDSSO implementation I hope to use should allow custom implementation of authentication, as I hope to call API's provided by both domains during authentication to confirm a user exists in at least one of the domains user database.
I've been looking at Sun's OpenSSO which seems to provide a means to extend its AMLoginModule class yet this seems to be a long thing and more annoyingly they seem to stick to GlassFish.
I've also considered developing a custom CDSSO to solve our needs. Is this advisable?
Is this achievable using Suns OpenSSO considering the disparate user database as I there will be no need to make use of the User db that OpenSSO requires?
Are there any simpler means of achieving what I intend to achieve?
In addition both applications which exist on the two domains were developed using PHP. How does this have an effect considering Suns OpenSSO is based on Java EE?
Are there any clearly specified steps on implementing OpenSSO and or any other SSO implementations from start to finish?
I suggest you to use simpleSAMLphp in order to deploy an Identity Provider and 2 Service Provider (for each app).
SimpleSAMLphp allows you to select multiple authentication source and is not hard to build your own authsource that consults the 2 databases.
My experience in SAML says that the fact of not consolidating the Identity of the user in 1 unique authsource is a bad idea due several reasons:
* identity conflicts: what happen if you have the same user registered with different mail (if that is the field yoy use to identify the user) and you try to access? You could be logged in different account each time.
* what happen if you add a 3rd service, do you gonna add a 3rd database
* what happen if user change its data in one app, the other gonna be no synched?
* what happen if user uses different passwords?
I recommend you to execute a migration process before adding the SAML support and build a unique database for all your identities and unify the registration/edit profile/password recovery process of both sites in one.
SimpleSAMLphp has good documentation, but I can provide to you any documentation related to the process that I suggested.