I have some clients that use SAML IDP providers like Okta and Centrify. I just implemented SAML, and I want to know what information should I send to them when they are asking for EntityID. My SP consume url is like app.mycompany.com/saml/consume, I think the EntityID could be the same as the consume URL. My question is if I should send diferent EntityID for each customer. For example for client A something like clientA.app.mycompany.com/saml/consume, for company B something like clientB.app.mycompany.com/saml/comsume.
Thanks for your help.
What you need to send them is the EntityID for your SAML Service Provider. Depending what you have used to implement this, it can be obtained in different ways. If yo have a of the shelf software you usually export a metadatafile where the ID is located inside. If you built it yourself, it depends. This is the ID that you give in the issuer field when you send messages to the IDP.
Related
At the company I work for, we have our own Active Directory setup. We also have a number of external partners who each have their own Active Directory setups. We are trying to use Azure AD B2C to create a single location to sign on. Adding multiple identity providers is easy, but buttons show up for each provider and due to privacy concerns we can not allow our partners to know who else we partner with. We wish to ask for an email, and direct the user to the correct identity provider based on the domain of the email.
I know there are ways to do this, however all of the ones I have found so far are extremely convoluted. The requirements for this feel like they would be very common in many businesses, so the concept that the easiest ways to implement this require approximately a hundred steps doesn't seem right.
I'm aware of Home Realm Discovery, but like above all examples I see of it require immensely complex setups (custom policies with claims providers calling an azure function to query from a database to return the idP), we already have to setup the Identity Providers is there really no simple way to say "emails from parter1.com use this provider, emails from partner2.com use this one"? If not, could someone explain the lease complex way of achieving this?
See this sample which collects email and does the HRD based on domain name.
https://github.com/azure-ad-b2c/samples/tree/master/policies/home-realm-discovery-modern
You must use custom policy if you collect email in the B2C page.
If you collect email in the app, then you could use a User Flow with a domain_hint param. You don’t need to do any xml work, just pass a domain_hint parameter equal to the idp name in the portal.
https://learn.microsoft.com/en-us/azure/active-directory-b2c/direct-signin#redirect-sign-in-to-a-social-provider
I would like to make a partner connector for Data Studio with OAuth as authentication method but
I have a little problem as in my case authorization server is different for every user which means that following parameters are unique for every user: AuthorizationBaseUrl, TokenUrl, ClientId, ClientSecret.
Is it possible to make a partner connector with OAuth and make those parameters configurable before starting OAuth?
Thanks a lot :)
Since your AuthorizationBaseUrl is different for each user, the only solution I can think of is to develop your own landing page for each user and use that as AuthorizationBaseUrl. From there, you can collect the correct URL from the user and redirect them as necessary.
Can anyone tell me what the exact function of the NameID is in the SAML response?
What does it represent?
Do you typically do something with it when received in the response?
We have done some implementations in the past, but we only use the claims that come along with the attribute assertion.
It's the primary key between two systems.
Two IDP; A and B. The identity repositories underneath these are completely different.
The users in A are completely different to the users in B.
An application is protected with A but B's user's want to use it. So A and B are federated.
A user in B navigates to the app., gets redirected to A, uses Home Realm Discovery to get to B and then authenticates.
NameID is used to pass some attribute (typically email address or UPN) from B to the application. This identifies the user to the application.
I am trying to make my web service identify specific client data to return as JSON. I am not sure this is the right way, and I'd love some advice.
The way it currently works is:
Database table for users with an appropriate company_id where they belong.
Upon logging in, an authentication service issues JWT tokens with the company_id in the token payload.
The clients sends HTTP requests with the token, after which a service verifies the validity of the token, and then the specific route returns data with SQL doing a WHERE company_id = company_id_in_token.
The red flags I'm running into are:
Having user data in the token payload. SSL will negate this, but I am worried about bad design.
Having to include a company_id column in every single table for the filtering.
Please, I kindly ask you to rip me a new one.
If you refer to the OpenID specification, it states that you send the id_token, but signs it for later verification. Also, if the upn or sub claim is available, you can infer the tenant from this data. However, in case if the userin question works on behalf of another tenant, special headers are required to infer the tenant, example contextual tenant can be a header that contains the tenant under context.
In case of having tenant id column, it is a good practice to have a tenant id column in the core business objects tables. There will be no tenant id column in a table that is dependent on the core business object, because it by itself doesn't convey any significance.
HTH
I have a web project in AngularJS and using NOdeJS and ExpressJS on Backend.
I have a contact form in my application when I click on submit form data is sent as an email. This I have achieved using npm package called nodemailer.
But, now I wanted to check if that email id exists in real world (fake or real) before sending an email. So what is the best way to achieve this?
Can any one help me with this?
Thank you
There are some open source api like http://api.mailtest.in/v1/XXX
Where XXX is the domain from email. Which means if XXX exists as domain you can assume that mailbox might exist. Try using curl / parser to fetch the response via api call if its true means domain exists and email might exist as well.
Theoratically its possible by actually sending email and verifying the response itself. Check this https://github.com/hbattat/verifyEmail
But still there are certain conditions, many times the responses are not being sent by Mail Exchange servers for security reasons. Also your email can be blacklisted by doing this.
The real world scenario might be simple with user interaction, send email and ask them to verify their mail using the secret shared in email.