I want to use Cognito Federated Identities with multiple Authentication Providers, and I want to manage my own user database so I have a simple immutable unique user id for other areas of the application.
What would be the correct way to trigger a lambda function that inserts newly authenticated users into my user database?
If I was only using Cognito User Pools I could use the offered triggers, and would create a mapping of the User Pool's unique "sub" id to my applications user id, but if I use other Authentication Provider's (Facebook etc..) through Federated Identities there are no triggers offered.
I cannot see any triggers within Federated Identities.
I understand User Pools can now do federation within User Pools, meaning a Facebook sign up there would create a User Pool identity which would have a "sub" id I could use, but I feel the federation in User Pool's is not as mature and strong as in Federated Identities, there are also less Providers to choose from.
Secondary question: Is there a best standard for mapping Authentication Providers ids to my application user id? I understand sub is an immutable unique id for User Pools, but Federated Identitie's "Identity ID" can merge and thus change so I guess best practive would be to use each Authentication Provider's unique id?
Related
I have a Cognito Identity Pool set up to use a Cognito user pool as a source of identity. Now, in my case the Cognito User Pool has 2 different client id, one for my mobile application and one for my website. In order to support login from both I need to add both client ids in the Authentication Providers settings but it seems that you can add only 1 client id at a time. Is there a way to configure Cognito Identity Pool to accept 2 different Cognito Pool client IDs?
I don't wanna use the same client id cause I need to do different user validations on user sign-up based on where the user came from (app or web) and the client id is the only parameter passed to my lambda that allows me to identify from where a user came from.
From the Identity Pool Cloudformation docs, it looks like you can provide a list of identity providers. A user pool identity provider is defined as the user pool ID plus the client ID. It seems like you should be able to specify two different ones with the same user pool ID and different client IDs. I don't know whether this is possible through the console.
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
I plan to use IdentityServer 4 on ASP.NET Core with ASP.NET Identity as the data store. This is the first time I use a central authentication/authorization and I am wondering how to solve the following question:
Assume I have users with claims like name, role etc. and a Web API (scope) that allows these users access to measured values from hardware devices. IdentityServer will allow me to authenticate known users but now I need an access control that knows which users may access which device data.
Where do I store this information? Since it is specific to the scope I guess it should not be stored in the IdentityServers store. On the other hand, if I store it in the scopes own database I somehow need to connect it to the users defined in the IdentityServers store. Should I define user IDs that are unique to all scopes and IdentityServer?
You will need to correlate the User Ids that IdentiyServer returns with users defined in the scope's database.
I believe that there is a User table and a UserLogin table where you could track the different logins for each of your users.
Then, in the scope's database, you can then specify which users have access to what device data.
This is a bad idea and will probably lead you down a road that you should not.
This means that your client application requesting the scopes will need to know which user has access to which scopes even before requesting a token from your IDP (otherwise your token request will not work). Rather model these as user claims. Then on your WebApi you can do normal claim based authorization.
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)