We are considering getstream.io for a B2B multi-tenant SaaS application's notifications feed.
Obviously, it should not be possible for users of a tenant to view and follow notifications and users of other tenants, respectively.
We need to take care of this separation in the backend anyway. But I wondered whether there is a smart way within getstream.io to support this.
Any thoughts/advice?
There isn't. You could create different "apps" or "feed groups" but those are all manual things.
The best way is to check on your application level, before you send any follow API calls to Stream, like you already have multi-tenant checks before logging in, viewing content, exporting stuff, ...
Related
I have some doubts regarding the custom connector we are trying to build for docusign : -
Regarding the license plan that need to be bought by the customers who will be granting access for our connector to collect data from their docusign organization account. I am looking at the link https://www.docusign.com/products-and-pricing. API access support is mentioned in only the advanced solution. So I was wondering whether only we need to have "Advanced solutions plan with APIs support" plan or all our customers need to API access support in order to fetch their data.
As per the documentation, to make the REST API calls we need two fields 'base_uri' and 'account_id' (https://developers.docusign.com/esign-rest-api/guides/authentication/user-info-endpoints). Now, the response of userInfo API call gives an array of accounts and its respective fields. My doubt is, if multiple authenticated users (more than one accounts) are returned in this array but all are part of same organization, will they all have different account_ids. Main concern here is, will there be several Base Paths (https://developers.docusign.com/esign-rest-api/guides/authentication/user-info-endpoints#form-your-base-path) to make API calls?
2a. Further question is, what is the significance of 'is_default' field?
Is this related to main account (if is_default is true) using which we will create our Base Path?
Since this is a tech/engineering forum I'm going to answer only question #2 as question #1 is more of a business/sales question.
The reason you may get multiple accounts is that an authenticated user in DocuSign can be a member of multiple accounts. That said, it's the same user. Meaning, say foobar#blah.com has an account 123 with company X and account 456 with his school, then it's possible that when foobar#blah.com authenticates (With the same password!) to DocuSign we have a list of accounts associated with that user. We give you all of them when you make the API call. The default one is the main one that you would see when you log into our web app. You can decide yourself as the user which one is the default. Users who log into our web-app then see an option at the top-right to change accounts.
and yes, every API call is associated with a specific account. So when you construct the urls for your API - you do need to know which account for this user you are making the API call for. Your application can decide how to handle this.
Hope this helps.
In my app I want to have some feed where different users can add activities
How can I do this? Are there any settings of user rights?
It would help if you could elaborate on what you are trying to build (e.g. what kind of user ACL you are trying to offload to Stream) and whether you are using an SDK or the REST API directly. Multiple users can add activities to the same feed.
Regarding user rights, permissions they would be embedded in the JWT token when you're doing server-side authentication, as exposed here.
We are building a enterprise product, and expect a lot of customers, to not have active directory of their own.
We plan to use AAD as our IAM provider.
We plan to create a master AAD for the product, and then invite users of each customer (tenant) as external users to the master AAD, using their business email id. Each set of users for a given customer, will be added to an external group for manageability.
Would this be the right approach, for supporting multi-tenanted IAM for a product hosted in Azure?
It's a pretty hard question. AAD's multi-tenancy basically requires the org to have an AAD to have proper separation etc.
But in the case of an org not having an AAD, this is one option.
One crucial thing you must not forget with this path is to turn on the option in the AAD tenant to restrict Guest user permissions. This makes it so that the invited users can't just go to portal.azure.com and get a full list of all users in the tenant. At least usually this is a desired thing when multiple clients are in the same tenant.
Other options could be:
Setting up an AAD tenant for each customer
Good separation for customers
There might be a limit how many you can create
I'm not aware of an API you could use for this (but hey Selenium works :D)
Set up your own identity provider with e.g. IdentityServer
Maximum customizability
Lot of work for you to develop and maintain
Everything would of course be easier if they just had an AAD :)
It would depend on some details of the approach you want to follow. If you are expecting for them to use their business email, then you may consider having Single Sign-On (many organizations expect not needing to duplicate accounts and you may want to delegate your customers the hassle of resetting passwords).
Also, you need to determine what kind of isolation need(do you want to have a single set of users or have a clear separation by tenant?) and the budget (AAD cost is measured on a per-user basis) you have for this? Azure AD B2C could be also an option, or as #juunas mentioned, implementing your own solution with something like IdentityServer.
I'm trying to get my head around SSO concepts and how they fit to my situation, and I've got to the point where I'm a bit stuck. Assuming we use something like Azure AD, or Ping Identity or something along those lines, we want to enable social login (google account / facebook etc) - that is all fine. The bit I keep getting stuck on is how do I control the claims to attach to that identity?
Process (in my head) overview:
- User logs in with google (facebook etc) account, they associate the google account with their 'legacy' account (i.e. link up their social login with their internal identifier that we as a business identify them as) what what ever that process is, does not matter for this discussion (i dont think).
Now when a user logs in with their social account, how do I perform the lookup of that mapping to their internal identifier to add it as a claim, and add the related other claim for that user based on information my organisation knows about them (e.g. If they are over 21, what 'level' of a member they are etc).
I get that if we had one RP using SSO, it as the RP could perform this logic, but we have the situation where we have several internal (and potentially externally managed) systems (4-5 currently) we want to tie together using SSO - which will rely on these claims for access / personalisation etc.
The closest I have seen to this is the concept of a RP-STS - which would effectively from what I could work out sit in front of Ping / AZ AD to form part of the chain, so so it can do the internal lookup and add additional claims as necessary - does that make sense as a concept? Is that the right approach?
I'm sure this can't be un-common - but i can't seem to find any good example / documentation around the full integration (plenty on just AZ AD / Ping etc) that we need. There must be off the shelf products that can do this? (We really dont want custom SSO implementation / components if possible)
The closest I have seen to this is the concept of a RP-STS - which
would effectively from what I could work out sit in front of Ping / AZ
AD to form part of the chain, so so it can do the internal lookup and
add additional claims as necessary - does that make sense as a
concept? Is that the right approach?
That is exactly the role of an RP-STS (or "Federation Provider" in some of the literature). It sits in between your apps and multiple "Identity Providers" and is usually responsible for 2 things:
Protocol transition (e.g. your app might be WS-Fed or SAML, but Facebook is OAuth2)
Claims transformation and enrichment (e.g. add, remove, transform claims based on some logic).
There are several implementations of this with various degrees of sophistication/flexibility, and trade-offs:
Azure Access Control Service can do #1 and (somewhat limited) #2. But it is unclear whether the service has any future or if it will be subsumed by Azure AD.
IdentityServer can do all. It is OSS so you "own" it (e.g. host, operate, customize, etc). It's a great implementation, used in production, written by experts (Dominick Baier & Brock Allen) and very flexible.
ADFS can do some (limited # of protocols, proprietary claim transformation language that is complex to debug, but works). You have to host ADFS yourself. This is a MSFT product.
The company I work for offers similar capabilities too.
I am creating a web-page/website that integrates all my accounts into one spectrum, as in, from this page I want to use this page to log into my mail box online or any other site that requires authentication. All i want is a central login panel. enter my unname&passwd and get redirected to my mail. Is that an impossible question to ask?
It sounds to me like you want to consider using OpenId, which is a standard, fairly widely adopted form of single sign-on. Used by this very site, in fact, and supported by at least two of the three companies you mentioned: yahoo and google. Hotmail does not currently support it.
It completely depends on the individual service. You'll have to investigate each service to see if they even allow you to authenticate against their servers remotely. In the event that they do allow it, it's still up to the service whether or not you'll be able to retrieve any kind of information from them after logging in.
Banks in particular are very unlikely to give you any way to interface with them and the ones that do will likely require a monthly access fee.
You want to look into SAML, an XML-based standard for exchanging authentication and authorization data between security domains, that is, between an identity provider (a producer of assertions) and a service provider (a consumer of assertions). SAML is a product of the OASIS Security Services Technical Committee.
With SAML, you can communicate between the major single sign on (SS0) technologies like CAS, OpenID, Shibboleth, AD/LDAP...