Is it possible to create a new realm for the user after the registration process?
I'm trying to build a multi-tenant system.
Each user, after registration (over Facebook, Google etc), must have his own realm, where he can managed his own users.
Is it possible, and if yes, then how?
Thanks.
Related
I am building a Laravel webapp, where I need to implement a custom registration process. Now I am not sure, whether I can/should use the built-in Authentication features from Laravel or not.
I have three types of users:
Admin users: My colleagues in my company who talk to clients, onboard them, etc.
Clients: Users who create certain tasks, that need to be done. They could more or less use a "standard registration" process
Service Providers: Users who fulfill tasks for clients. They need to be onboarded by our company. So our admin users would create their user profile and send them an invitation link.
Especially the Service Providers are giving me a headache. Is this kind of custom registration flow possible in Laravel or do I have to build my own custom athentication to accomplish this?
Thank you for posting your question. I have implemented Laravel Authentication with custom features before, I would recommend you to take the following steps:
Install Laravel Authentication.
Update users table with a column name type that will distinguish between users.
Create middleware for each user. Middleware helps you which user can access or perform which tasks.
If you have different elements for each user then you can also implement policies or gates to show specific elements on your blade template according to user type.
I would not recommend creating custom Authentication for this scenario, as you have to implement proper session handling throttling, forgot password, verify the process along with emails and notifications. which is built-in by default in Laravel.
If you want to edit the register and login function you can do that. ;)
I'm trying to create an app within the Azure app management portal that will serve as a template to be used with any tenant. Basically what we are trying to do, is create a connector that will be approved using admin consent, and receive application level permissions to read all the emails in the organization using Graph API.
What I have managed to do so far is create an app within our own tenant and get application level permissions for this tenant only. This enabled me to successfully read all emails in my organization only (which is not possible using delegated permissions).
What is the right way to receive application level permissions for any tenant, using admin consent? Is the only way to do it, for the specific tenant to manually add an application that will receive admin consent?
I am using django with the social_core module.
Something does not add up...
Thanks.
You can register a single application (with a single client ID and set of credentials that you control), configure the permissions you desire/require, and then customers from different tenants can each grant admin consent for your application, in their own tenant.
If your application/service does not have a sign-in experience (i.e. it is exclusively used as a background service and users never sign in to it), you can construct the admin consent URL, such as:
https://login.microsoftonline.com/organizations/v2.0/adminconsent
?client_id={client_id}&scope=.default&redirect_uri={your_redirect_url}
You can read more about the admin consent endpoint at: https://learn.microsoft.com/azure/active-directory/develop/v2-admin-consent
We're trying to figure out how to submit to the marketplace, but are not sure what we need to do to alter our existing signup flow to accomodate the SSO requirement
Our app was not originally built to be a marketplace app so our signup flow is built for individual users. We are already following the OAuth2 flow as outlined on this documentation page. However, its not clear to me how this works for an entire org when installing from the context of a marketplace app.
Does the admin grant access to all the individual scopes we currently request for the entire org at once? Is there need for some sort of service account or something since we currently are requesting offline access? I'd like to understand what changes we need to make to our server's signup flow in or whether it is just a scope / manifest mismatch.
We currently request the following scopes from an individual user when signing up.
['email', 'profile' ,'https://mail.google.com/', 'https://www.googleapis.com/auth/calendar'],
Exact questions are...
What (if anything) do we need to do to alter our current individual-focused signup flow to accommodate a Google Apps Admin signing up their whole domain?
What scopes do we need to in our Google Apps Admin listing and how do they relate to the scopes we currently request from individuals?
There are not so many changes if you are already using three legged OAuth2.
The first change would be in you project in the developer console. There you need to enable the Marketplace SDK and make the necessary configurations. Here you will add the scopes that your app will request and those are the scopes that the admin will see when installing the app.
The admin will see the scopes your app is requesting, and he will decide if it's ok to install the application in the domain. If it is approved, then yes, the admin would grant access to the entire domain.
Offline access is part of the Oauth flow, after you receive the refresh token, you can continue refreshing the access token without having the user to grant access again.
It is not necessary to have a service account. The service account has two purposes:
To manage information related to the application. In this case the service account can have access to it's own drive to store and retrieve information that is related to the app functionality.
Impersonation of users. When using domain delegation of authority, you can use a service account to impersonate any user in a domain and act on it's behalf to make API calls.
To deploy your app, you also have to create a new project in the Chrome Web Store, with a manifest for Marketplace.
To answer your questions:
It's not necessary that you modify your current oauth flow. The admin will install the app in the domain, but when a user access to the app, the process for authentication is the same as individual.
The scopes in your Marketplace SDK configuration should match the scopes your app will use. This is mostly for security reasons, it wouldn't be safe if you install an app with some scopes and then the app uses different scopes.
You can try your app before actually deploying it by adding trusted testers in the chrome web store dashboard or in the Console API configuration. This way you can check if your flows and all the configurations were done correctly.
Hope this helps. Let me know if you have more questions.
I'm building mobile applications using .NET. What I'm looking for is a way to manage user sessions and info using Azure Mobile Services. I've read a lot about the authentication in Azure Mobile Services, but this only authenticates a user via Facebook, Twitter, etc ... to access azure services.
I'm looking for user session management, i.e. register, login, logout. Be able to save and retrieve user info, i.e., save certain info against the user such as age for example. Also session management and caching, i.e. the user will remain logged on when the app is closed and re-opened. Also azure mobile services doesn't seem to provide a way to allow me to register users via email.
Basically, If anyone is familiar with Parse, I'm looking for having similar functionality in Azure. Can anyone help please ?
Thanks
Out of the box, Mobile Services provides easy authentication with social providers (Facebook, Twitter, etc) and Azure Active Directory. If you want to do registration via email, you'll have to create a custom auth system. This is going to be more complex than just flipping a switch and using Facebook auth, but totally doable and I can point you in the right direction. First, check out this post that will explain how you can create a registration / login system using custom API and the script backend. If you're using a .NET backend, you'll need to alter thing a bit (the samples are in JS) but it should be pretty easy to convert. The only piece that is really missing from that post is how to do email verification. To do this with Mobile Services, I would suggest the following.
Sign up for a SendGrid account (free in the Azure store)
From your script, after registering the user, generate a random alphanumeric string that is saved to their account / user record in the table.
Use the same string to create a URL which you can send to the user's email address (check out this tutorial for sending email via SendGrid and Mobile Services).
The link can either go to a different custom API or a web front end. When that endpoint is hit, it should update the user record to show that they have verified their email address.
I'm converting an existing Google Apps Marketplace app to support OAuth2.
I understand the use of access keys to identify the user account but how can this be used to link a user to a 'company' or 'domain'?
Our app supports having multiple user logins under one business account - we need to be able to identify what company a user belongs to using OAuth2. How can this be done? (we're using C#).
Is there an additional user API that needs to be called after initial authentication, if so, which one? (we're using C#).