I am starting to design Multi-tenant system and already read the article:
http://msdn.microsoft.com/en-us/library/aa479086.aspx
Any case, I have couple of question related to authentication.
For example, we need to support a customer that requires Separate Databases.
More precisely, the customer uses Separate LDAPs (LDAP per tenant).
The problem I can not solve that the authentication framework need to know a tenant before the authentication to authenticate against the appropriate LDAP.
How a user selects tenant during the authentication?
The form authentication:
Should we develop a special form login with 3 input fields: user name, password, and tenant?
Should we show to a user the list of all tenants?
This is information disclosure, a user can see the list of all tenants in the deployment.
Should it be free text filed? In this case it is error prone.
Other types of the authentications:
How tenant information can be send if we use Basic Authentication? Digest Authentication? Client Certificate Authentication?
Any point to already existing(free) frameworks will be appreciated.
As you correctly mentioned, You have to identify the Client/Tenant ID while you allow the user to login to the multi tenant application. There are basically 3 ways to identify the Tenant ID.
use company code text field where your users can enter their tenant id,password/username to authenticate (Error prone, users may not enter the id correctly).
collect the username and password and identify the Tenant ID by yourself, but you have enforce Unique identity (email) for all the users in the system. (Preferred)
Assign unique Sub-domain for each tenant (Preferred). using unique url of the customers, you can identify the tenant id and you can connect to appropriate DBs of the customer.
WRT to Authentication, I personally don't recommend Basic Authentication because of the security vulnerability, So you could either go with Digest Authentication/ Client Certificate Authentication.
Related
I'm designing two micro services one for Teacher and other for Student. Now my question is what is the best approach of storing users and doing Authentication Authorization :-
Centralized Auth server which will store user roles as well as all the info.
Centralized Auth server which will only store roles but the user info will be Stored in the databases of their respective services (Student, Teacher)
No centralized Auth server but redirecting login request to either Student or Teacher as per the role in the request body and it will be the responsibility of Gateway.
I want to know the pros and cons of these approaches. If there is any better approach then please share the same.
P.S :- Multiple roles can be assigned to a single user.
I would go for the first approach. Rather than "centralized Auth" server it would be more of a "auth micro service".
Now the important part is how to handle authentication itself. In general you could either use a session or JWT.
For micro services I think JWT is a perfect fit. If you use session you basically "centralize" your authentication and authorization. What I mean by this is that after a user is authenticated, every time the user makes a request all the micro services that react to this response must check on the centralized session. This will not only increase latency but it just doest fit with the distributed system. The point of using micro services is to have make replicas of services and so scale horizontally.
If you use JWT, the micro services only need the secret key to validate the token. Basically no centralized store(session) for authentication infos.
About the "auth service", I would suggest you to store authentication and authorization related data only(including user info related to authentication. phone number, email, name etc. you probably would use this in case user needs to change password, forgot password etc.). Other specific data related to a specific role can be stored in the corresponding service.
The Requirement is maintaining single JDBC(postgreSQL) user store for the below applications,
Create a user using SCIM api in to wso2-is.
Authenticate my microservices using oauth2 client of service provider.
Integrate WSO2-IS embedded read only LDAP for BPM(Camunda) application authentication and authorization.
I am able to do the first and second points and created a single JDBC user store for users.
For the third point, not able to get the users from JDBC user store using embedded read only LDAP.
Can you help me in this flow, is there any way available in wso2-is to achieve this requirement?
You can use the create a Read-only LDAP secondary user store for LDAP and use it for the BPM(Camunda) application authentication and authorization. You can find more information about secondary user store here
When authentication the users will be validated with all the existing user stores (primary and secondary). The possible issue will here is if the same username exists in two user stores.
If you provide user store name appended to the username, it will validate on the specific users.
For example, if the user store name is 'BPM', then you need to append as 'BPM/<username>'
I am trying to build a pure JavaScript rest-client application that must support anonymous retrieval of information from a REST server that already supports JWT for authentication/authorization for external applications. The server is already being used by other client applications supporting multi-tenancy. Actually embedding the tenant information in the JWT.
Besides that the application needs to support users(human beings) that will want to mark(or select) some resources as favorites so a mechanism is needed for users/role creation and further authentication/authorization for the users. But these users can't be isolated to a single tenant, they will want to use across tenant resources.
So, right now I found that I need to use a JWT value for the anonymous data retrieval that of course should be tenant-agnostic. This means that I have to create an user with a special role that just have permissions for read only resources, except for the permissions for user creation (when the clients do sign up) again this should be tenant-agnostic. And when the user log-in into the system the JWT should be replaced for the one that have the user credentials again tenant agnostic. I am not sure if this is entirely correct, so how should we handle a situation like this ?
My other concern is, that we have the same back-end supporting authentication and credentials storage for human clients (tenant-agnostic) and application clients (tenant-aware), so there is logic that is a little bit more complicated in order to handle the privileges and tenant restrictions here. This could be just my impression but I feel that there should be a separation between application users and human users in the logic and/or data store.
But I am not completely sure and I want to know if some of you have previous experience or could have some ideas about this topic ?
Can you try the following approach, Create the users, assign the users with a read-only role for the tenants to which they need access to.
The data would be like
User1 - tenant1 - administrative role
User1 - tenant2 - data reader role
User1 - tenant 3 - user role
In the jwt, we ensure that the user is authorized. Then we get the list of accessible tenants and see if he has access to the requested tenant data w.r.to the above data and then complete the authorization.
HTH
In short: Can I use OpenID oder OAuth for anonymous logins on my web service?
Described in more detail:
Scenario/Background: I'm going to provide online-tools for mental health related exercises. The users should be able to see their completed exercises after each login, but I don't want them to register at my service—because I don't want to store their e-mail adresses, passwords, not even nicknames or anything like that (not even hashed!), because it could reveal the users' identities. I want to keep their privacy perfectly safe by not storing anything that relates to the offline identity.
Problem: How to perform the login (or how to recognize recurring users) without credentials?
Approach(?): When I use my Google account to log in at some third-party web services, I'm asked wether I want to share my profile data, e-mail adress—and what else. Would it here be possible to reveal nothing? The only thing, the service would know, is that somebody has a google account and knows the password. To me, it's completely unimportant who the owner is, it's just important to recognize the same owner after each login—let's say by some kind of anonymous token id.
Is this approach working?
Are there other approaches for anonymous user logins—without storing data?
Use OpenID Connect. OpenID Connect is a specification built on top of OAuth 2.0 (RFC 6749). You can delegate user authentication to an Identity Provider (such as Google) that supports OpenID Connect.
An IdP will issue an ID token to you after successful user authentication. You can find the user's attributes such as name, email address, etc. in the ID token. So, you don't have to manage users' attributes any more if you use an external Identity Provider that supports OpenID Connect.
(Addition for the comment)
OpenID Connect Core 1.0 has defined 6 standard scopes as listed below. These values can be included in scope parameter of an authorization request.
openid
profile
email
address
phone
offline_access
Among the above, profile, email, address and phone are defined in "5.4. Requesting Claims using Scope Values". They can be used to request some attributes of a user to be included in an ID token which will be issued by an authorization server. For example, when email is included in scope parameter, the ID token issued based on the request will contain values of email and email_verified (if the authorization server supports the attributes).
So, if you want to minimize the number of attributes contained in an ID token, avoid including profile, email, address and phone in scope parameter. In other words, scope parameter should contain only openid.
In an ASP.NET MVC 4 application using the .NET 4.5 framework in conjunction with Azure Access Control Service (ACS), I want to provide the users multiple authentication possibilities (i.e. Google, Facebook, Windows Live, etc.). What is the "best practice" for associating a single user to multiple identity providers?
For example, say the user logs in with Google one day, then goes to another browser the next day and logs in with Facebook. How would I know to associate the Facebook login with the previous Google login to the same user?
Look no further than stackoverflow itself for a good example of this. Click your user profile and then select "my logins".
When a user creates their account, they select which identity provider you want to use to sign in. Under the hood, your application creates a new site-specific unique user ID, and links it with a 3rd party provided unique ID. (You might use email, but most identity providers will also provide a unique user ID claim that doesn't change, even if the user changes their email)
Now, after the user has signed in, they have an account management control panel through which they can establish additional links to other identity providers.
I see two options for achieving this:
Have your MVC application persist account links. When a user signs in, you query your account link store using the 3rd party unique ID claim and resolve your site specific unique user ID.
Use the ACS rules engine. You would create one rule per account link. For example, lets say I can sign in with either gmail or liveid and my unique id is 1234. Two rules look like this:
google + me#gmail.com --> output user ID claim 1234
liveId + me#live.com --> output user ID claim 1234
For the unique ID output claim type, you can pick from the available claim types or designate your own. ACS has an OData based management service which you can use to create these rules programmatically from your MVC application. Here's a code sample.
If you are using ACS, you can translate the information from each IdP (e.g. Gogle, Yahoo!, FB, etc) to a common handle using claims transformation on ACS. A common handle people use is the users e-mail. But if you want to accept many e-mails mapping to the same user, then you'd introduce your own unique id (as a claim) and map IdP supplied claims into it:
myemail#gmail.com (e-mail - Google) -> (UserId - YourApp) user_1234
myotheremail#yahoo.com (email - Yahoo!) -> (UserId - YourApp) user_1234
64746374613847349 (NameIdentifier - LiveId) -> (UserId - YourApp) user_1234
You can automate this through ACS API. You should also probably handle the first time user logs in into your site (e.g. asking user for an e-mail and sending a confirmation message that will trigger the mapping).
Presumably, you are using this information to retrieve data from a local database in your app, otherwise, you could just encode everything in claims and not worry about any equivalences. Claims are often a good place to encode common profile data. (e.g. Roles, etc)