5. Authentication
The Bayun SDK (in conjunction with Lockbox Management Server backend) handles the encryption/decryption keys, and lockboxes, based on the logged-in user, and the tenant/company whose data in the app this user should have access to. So an enterprise application developer should choose the companyName and the companyEmployeeId below, using the same criteria that are used inside the application to distinguish between different companies (sometimes also referred to as tenants in a multi-tenant application), and the employees. For example, for the Gmail app (or any other GSuite App), the login-id of the user is the email address in the form of “username@bayunsystems.com”. Assuming “bayunsystems.com” (the domain-name part of the email address) is registered for a corporate-account with Google, it determines the company/tenant uniquely, and GSuite server will use policies applicable for the company this domain-name maps to. The “username” (or the complete email address “username@bayunsystems.com” itself) is the unique user-id of the user for that specific company, and determines the policies applicable to the logged-in user. So in this case, the developer should use “bayunsystems.com” as companyName for selecting the tenant, and preferably complete email address "username@bayunsystems.com" as companyEmployeeId (even though in some cases just the “username” part might suffice, it's not recommended). Note that some applications allow users with any domain to login to any tenant, even if the domain-name of the user doesn’t match that of the tenant (e.g. accounts for certain contractors of an enterprise using their own email address for login rather than corporate-emails issued to employees of that enterprise). In fact some users could even have access to multiple tenants as well in a multi-tenant application via the same user-account. In such cases, the companyName parameter should always match the domain of the tenant the user is trying to login to, and not the domain of the logging in user's email address. Also, the complete email address of the user needs to be used for companyEmployeeId here, as the domain part of the user could be different from the tenant's own domain.
For a consumer application, or consumer use-case in a hybrid application, the developer can use a single companyName for all consumer/individual users. For example, GSuite applications can use “gmail.com” for all users who have consumer email addresses in the form of "username@gmail.com". The same companyName can also be used for other individual accounts using custom domains without the domain being registered for a corporate account on Google (e.g. username@customdomain.com, where customdomain.com is not registered as a corporate account). So the single companyName chosen by the developer here serves as the default tenant for all consumer accounts that don’t belong to a specific enterprise tenant. And the companyEmployeeId should be the complete email of the user (e.g. “username@gmail.com” or “username@customdomain.com”).
Since both companyName and companyEmployeeId parameters are arbitrary strings, the developer can also use app's own internal companyId or tenantId for the companyName parameter, and pass app's own internal company-specific employeeId or user’s loginId as the companyEmployeeId parameter for BayunSDK. The only requirement for BayunSDK is that the companyName be unique across all the companies, and that the companyEmployeeId for each employee be unique within a given companyName. However something like this should be done only when the email address of the user or unique loginId is not available. For portability and consistency across multiple types of users, and various different types of use-cases, it is highly recommended for the developer to use the complete email address of user as companyEmployeeId when-ever available, and the domain-name of tenant as companyName, in most cases.
Initialize BayunCore
Import: import com.bayun_module.BayunCore
Get BayunCore instance with appId, appSecret, appSalt.
appContext: Application Context.
baseURL : Provided when an app is registered with Bayun.
appId : Provided when an app is registered with Bayun.
appSecret : Provided when an app is registered with Bayun.
appSalt : Provided when an app is registered with Bayun.
verifyDeviceLock : If device screen lock is active then true otherwise false.
User Login
You first need to authenticate the user with Bayun's Lockbox Management Server (LMS) using the login call (or register call for a new user) before you can make use of any other Bayun features in your app. Note that any of the login functions of BayunSDK needs to be called only once for a user on a new device to set up the context for that user in the device's secure enclave. There is no need to call this function every time the user starts the app, unless the user was logged-out by explicitly calling the logout function. You can choose to use Bayun's combined authentication & authorization mechanism as the primary auth for your app's users (e.g. for a brand new app, or for an existing app to replace the current auth) to keep things simple for yourself, and also provide a seamless passwordless auth experience to your users. Or alternatively, you can instead use Bayun's auth mechanism as a supplementary authentication (using additional security mechanisms on top of existing auth), or as a shadow authentication (using the same credentials as your own app), in conjunction with your app's primary authentication mechanism. If using it as supplementary or shadow authentication, make sure Bayun's register or login function is called only if, and after, your own app's authentication succeeds. Bayun relies on your own app's authentication to ensure correct password (in case of registerWithPassword) or email (in case of registerWithoutPassword e.g. with SSO) is used for a given (companyName, companyEmployeeId) combination, and the given user indeed has access to account with a specific companyName & companyEmployeeId at the time a user is registered with Bayun. The user is on-boarded onto the Bayun system after successful registration (which can optionally require explicit approval from an admin of a company or service-provider). Once a user has been on-boarded, the Bayun auth system requires use of the same password as your own app's authentication for all further login attempts if it is being used as shadow authentication (so make sure to call changePassword function appropriately in Bayun-SDK when-ever any user changes their app password for your app). If the Bayun system is being used as the primary or supplementary auth mechanism for the app, there is no need to keep any app-passwords in sync between the app and Bayun.
Last updated