The tutorial on OAuth here describes how to authenticate a client of composer-rest-server. After logging in, the client manually selects the default identity.
Is it possible to identify who the participant is from his email ID and setting it to default identity? For example, if alice#somenetwork.com [a trader] authenticates using OAuth, acl of trader are set automatically and her identity is set to default. If some other user logs in, his/her identity is set by default rather than the user choosing / having the right to choose the default identity after logging in.
Thanks
If alice987#gmail.com authenticates with the REST server, and then imports a card 'AliceTrader' and sets is as default.
When bob789#gmail.com authenticates with the REST server, he does not see the same Wallet as Alice. He has to import his own card and set to default.
If Alice and Bob have only 1 card in their wallets it will be the default.
In a production scenario, users won't be directly accessing the REST server, your client program will do that and so you can programatically set the defaults if you wish to.
Related
How do I best configure Keycloak so that a user needs to have an account for a client to be able to login into that client?
I have to replace a proprietory SSO-Impl. It deals with users, roles and clients much like Keycloak. However, it also knows about accounts. A user is only allowed to login to a client if he has an account for that client.
In Keycloak, if a user simply exists in a realm he may login to a client of that realm. Nothing else is needed. So no "account" is needed. In the old application, he needs an account as well.
What functionality in Keycloak is best suited to overcome this difference?
I have one idea:
Create a client-role in each client namend "HasAccount" and assign it to users. Then, restrict access if that role is missing.
This is discussed here: "Restrict client access in a single realm with keycloak"
It has at least two drawbacks:
It mixes authentication and authorization in the legacy app. I can understand that. But creating a role was already a workaround. That is why I described my initial problem here.
I have clients in 3+ languages/technologies. Adding functionality there seems like more work than in Keycloak.
Last remark:
Before you ask "This is not single sign on" anymore. It is only for administrative purposes. The admin can allow users to login into a client or not by creating an account or not. The user does not have to login a second time. If he is logged in in App A and has an account for App B, accessing App B works without logging in there.
A user is only allowed to login to a client if he has an account for that client. is really not a task for Identity Provider (IdP). It provides only identity and not authorization.
Of course you can ignore that and implement authorization as well. See: User attribute based web service access control by Keycloak
From the design perspective I would add auth reverse proxy in front of legacy app (but it isn't a best solution for SPA apps). Auth proxy will provide authentication via OIDC protocol and also authorization. Legacy apps may keep own OIDC authentication - it will be seamless auth from the user perspective, because SSO will be used.
Account entity - you can use group entity in the Keycloak instead of original account.
We are currently working on an Angular node application which uses WSO2 Api Manager and Identity Server . The current mode of login is done through emails which gets saved as WSO2 Carbon users . We need to allow users to login using their google or facebook accounts using OAuth2. I have implemented the code for fetching access token,refresh token on login through google on click of a button from my app . But How can i link it to save this user as a user in our application's identity server . I found the below link which helps in the process: https://docs.wso2.com/display/IS570/Logging+in+to+an+Application+Using+Google#50629d9a6ddf4769ae2d8953c5a25645 .
Can anyone suggest me whether this one would help ?
I would like to know how the google account user details will be saved as a user in our identity manager ?
Is it possible ? If possible, what all data will i get from google ?
I assume that you have already done the configurations for the communication between your application and the WSO2 Identity Server according to the description in the question.
From the description, I'm not certain that you have done the configurations to federate the login to Google. Follow the below steps if you already haven't done so.
Generate OAuth client ID from the google developer console.
Configure a federated authenticator in WSO2 IS with google authenticator using the generated client id and secret values.
Add newly created IDP as an option to the first step of your application.
More information can be found in here. From Google, you can get email and default profile attributes of the user. Reference.
Follow the same steps for Facebook login as well. More information available here.
Now the federated login is configured. Now you need to enable JIT provisioning for the configured Identity Providers above to save the user in the Identity Server when the user is logged in with those social login options. More information available in here. You have a few modes to create the user in the Identity Server.
I'm looking to use an identity service such as Azure B2C, Auth0 or OKTA to secure my application.
After the user signs up for an account, I need to display a custom registration form in my application in order to complete the registration. This form requires a business process behind the scenes and therefore it can't be part of the Identity Service (IDS are quite limited to capturing static data).
How do I ensure the user has completed the registration form on my application, when they sign in?
I'm thinking of using a claim such as "RegistrationComplete" and setting this to False when the user signs up. After they've signed up I can update this claim to be True.
I can't find any information online about this scenario so I not entirely sure its standard best practice.
Disclaimer: I work at Okta
Okta does have some features which should allow this. You can pull properties from the user's profile in Okta and put those properties on tokens as claims when the user is authenticating. So the user profile holds the state you care about. Your app/service can then read this claim from the token to determine if the form should be shown. Once the form is complete, your backend service can use the Okta APIs to update this user profile state, and then send the user through the authorize flow again to get a new token with the updated claim (specifying to not prompt for re-authentication when going through the authorize flow again).
There is a restful provider feature in azure ad b2c. Using the Rest Apis from any service along with custom policies in b2c, we can get user input and save that user input to any database. The REST apis can be used to orchestrate any step.
https://learn.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-rest-api-step-custom
Background Explanation
When it comes to Identity Server 4, I come to a road block when i think about the design of user management in the client applications.
At this point, I have Identity Server setup using ASP Identity User Accounts as its user store.
I've built the UI for adding users to the Identity Server User Store.
I've tested setting up a client which is an MVC application, and I'm at the point where i can successfully authenticate with Identity Server and receive the openid identity token in my client application.
Identity Server is providing my client application with authentication.
Now, i need to concentrate on authorization within my app. This is where i get stuck, I need to create users local to the application, where user privileges within the application are stored.
I will need to link / associate the user in Identity Server to the user in the client application.
One way to do this would be to store the sub in the identity token as a user claim in the client application database (Asp Identity). This way, when a user authenticates i can locate them in the local db, based on the sub in the token.
The sub would have to be the user's unique id in the identity server user store. This way, if the user's email is changed, we can still link the two user accounts.
The user accounts in the client application wouldn't require passwords or email addresses, it would be purely claims and roles that are used for authorization across the application, as well as any other application specific information.
Question
Communication between Identity Server and the client application must need to exist when creating users in the client application?
We need to associate the two accounts?
We need to ensure that the client user account being created also has an Identity Server user account to be successfully authenticated?
When in the process should these tasks be complete? Im looking for some guidance in the flow of the communication between the two applications?
EDIT
Is it feasible that there are no User Accounts in the client application at all?
By this i mean that all user claims for a user are stored in the User store of Identity Server.
When a client authenticates with the IDP it requests only the user claims that are specific to the client application.
Example user claims in the User Store :-
"clientA_role" : "administrator"
"clientB_role" : "user"
When Client Application A authenticates, it requests only the scope clientA_role
This feels bad!
Any suggestions?
If you have many client applications then the way I recommend to do the user management is:
User Management Service:
Create a separate service for users management that identityserver will use as user store and applications will use as user repository when user metadata is needed.
Also why would you do something like:
Example user claims in the User Store :-
"clientA_role" : "administrator"
"clientB_role" : "user"
why not
just "roles": "user"? and in your application you will protect your resources using Authorize[Role] annotation.
do not create different fields for different applications, think of it as general user management service, I am pretty sure that standardizing your identity management will make it easier and will gain you maintainability and flexibility.
IdentityServer service handles identity management:
might be a good idea to keep user store inside the same service providing authorization if you feel that your application does not have such deep users management needs.
again in this case, store standard claims and return the claims you need inside an id_token or access-token.
Update:
For a specific user that have different roles in different applications:
let us say we have the following:
1- User1 has user role in first app and admin role in second app, then
User1.Roles{"FirstAppUser","SecondAppAdmin"}
2- User2 has admin role in both apps, then:
User2.Roles{"FirstAppAdmin","SecondAppAdmin"}
In my requirement, i have users in the IS. And I need to log into other applications by entering his user name and password. then the application should call the service provider which is defined inside IS and check whether the person who is trying to log into the application is actually authenticated user, then user name, email and user permissions also should be sent to the application as the response from the service provider.
I'm using OAuth2. Using Is 5.1.0.
Can anyone please guide me how to implement this
Can I check it with rest client tool like postman also?