we have a scenario where we need two different authentication types (keycloak, Github) for the same pod .i see no option in the documents where I can add this option based on the incoming URL.
i have 2 different ingresses for the pod, do I have an option where we can enable different auth using some kind of condition based on the ingress url.
please give me some idea if that works..
Related
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.
In essence, only allow requests/responses to/from Azure Front Door. There are different options, however, I'm having trouble finding details on implementation and best practices. I think the proper solution would be to create a Virtual Network to use to integrate the two services.
One nuance exists, the Web Apps have staging slots that may require a different solution since they use Azure Active Directory to prevent public access to pre-production.
I found a little more insight here, but still found it a bit confusing.
It seems that if I have a custom domain with subdomains with Front Door, there should be an easy way to prevent direct access to the backend addresses of the Web Apps and only allow through the custom DNS and Front Door.
This was helpful, however, I'm still getting 403 from the Front Door, so I must be missing something in how to configure.
Middleware? This also was helpful, but seems to indicate it can only be accomplished by middleware and I'm running Node/Express not .NET Core. Is it true, it can only be accomplished through middleware code?
This also mentions the same details.
What is missing? How to configuration this across different application stacks.
The documentation is inaccurate when it states
< To lock down your application to accept traffic only from your specific Front Door, you will need to set up IP ACLs for your backend and then restrict the traffic on your backend to the specific value of the header 'X-Azure-FDID' sent by Front Door. These steps are detailed out as below:
It requires either setting up IP ACLs for your backend or implementing middleware code to conditionally match on your specific header value for 'X-Azure-FDID'. Both may not be required, the documentation is unclear.
I think you DO need both IP ACLs and checking the 'X-Azure-FDID' header. (I wish it was not needed...). If you only use IP restriction, your back-end is still open for all Front Doors around the globe, also those of other Azure Customers. And if you use only the check on the 'X-Azure-FDID' header, you are open for attackers trying to guess the header with brute force. Only the combination of IP ACL and checking the header will protect your back-end, because then you can be sure that the 'X-Azure-FDID' header was indeed added by a real Front Door service, and not spoofed.
See also this post, where it's explained clearly.
For example, Is it possible to have the native subscription based authentication and OAuth2 such that either one of these can be used for authenticating any given request?
At present, I have subscription based approach on the API frontend, but am interested in moving to OAuth. Id like to however keep clients who have been configured to use the subscription based approach unchanged if possible.
perhaps the answer is that , I must stick to 1 and only 1.
But feel this is worthwhile to ask since perhaps others may start with subscription based approach, and interested in moving towards an alternative.
Once solution I feel might be to create a seperate API front end for OAuth2, which points to same backend. That would satisfy the problem. However, Im hoping to keep the same api frontend. If that makes sense.
I don't think it's possible since if you won't pass the subscription key or pass an invalid one it will deny the request.
What you can do is use versions, so let's say v1 uses subscription key and v2 uses another authentication mechanism. So in summary, you'll duplicate all API's, but for v2 you won't assign a Product (won't require the subscription key).
I see how to get the list of groups, and how to get the members of each, but is there no way to get the list of groups a user (not just me) is a member of? I'm using v4 of the API on 11.9.11-ee.
You're correct. The API currently does not provide this capability. If it was added it would likely be an admin-only endpoint.
If you'd like to see this, raise a feature request at https://gitlab.com/gitlab-org/gitlab-ce/issues.
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.