I have a web application on which I am hosting some events like hosting a business meeting every week and these events are isolated from each other each event will have its own users and for their authentication and authorization, I want to use KeyCloak so in the KeyClaok context my client will be my web app and I will add the event users in keycloak now for the event part should I create a separate realm for each event? like I have a business meeting on 21st of May and the on 29th of May, so do I need to create new realms per event and add metting participants as a user in KeyCloak? please guide me on this do i need to create a realm per event or there is some other approach i can use ?
Related
I have a requirement wherein I need to perform certain action in my web application based on phone call receiving event that occurs in a third party application - Knowlarity SR calling app.
We are using Knowlarity Super Receptionist calling API to receive calls to a virtual number and then route those calls to call center Agents as per their availability. There is another web application we have built which call center agents uses to manage customers and orders. Agents login to this web application (web app in Azure) and places orders for customer who is calling over the phone from Knowlarity. Here the requirement is whenever Knowlarity routes the call to any agent and when the agent picks up the call, it should notify this action to web app (CRM) the web app should automatically redirect the same Agent to a specific page.
Please suggest a solution how I can listen to the call receiving event in Knowlarity and do some action(page redirection) on the web app side.
Thanks.
I tried writing an Api method in Web app which Konwlarity will call to send event notification with some information. Also tried implementing HttpHandler for this. Please suggest the correct approach for this. Remember that it is a Web app so multiple agents can login, they have their own session so how to handle this.
Hope you can help with this scenario. We have a browser-based support app that uses SignalR for customer chat. The solution comprises two web apps: admin.[domain].com and support.[domain].com. Both are C# ASP.NET CORE 3.1 MVC apps.
The admin app is used by the support engineers to service the chats. The SignalR hub is hosted within the admin app. The admin app uses ASP.NET CORE identity for authentication and authorization.
However, the support app has no identity mechanism - we need a "low friction" solution where the user simply connects to support.domain.com/{GUID}, no password required. The GUID is a SignalR group name pre-generated by the support engineer. Upon hitting this route, the support app calls AddToGroup(GUID).
The SignalR documentation states that Groups are not an effective security mechanism. However if the group names are GUIDs and we never send to all clients, then is this a reasonably secure approach?
Messages are only ever sent or received within a group. The GUID makes the Group Name very safe I would have thought.
Can the chats be eavesdropped easily if the group name is an unknown GUID? Is there a better/more secure alternative to this approach, without having the client enter a password?
As you correctly said, the groups are not a security mechanism. But in your case, what you want to do is fine because, as long as a user connects to the Hub, and the groups management is made by the admin, after a chat session the admin can remove the group so the user can't join it latter.
You need to make it clear that this is a public session like you can see in apps like whiteboards where users can join if they have a invitation link.
I also would recommend implement some ttl mechanism to groups expire after a while to user don't join a session latter.
At last, just do some defensive codding like, allowing only be 1 admin and 1 user in each group at a time, etc...
In instances where you have multiple clients and a central IdentityServer 4 instance which handles user auth/n, how would you go about managing user profiles from individual clients?
Current scenario:
user clicks on manage profile
user is redirected to a custom manage claims page on IdentityServer which a) loads all claims in a form, b) allows user to mod such claims and c) updates them with new values
user is redirected to the referrer URL (which then retrieves
these fresh claims via a token refresh which includes the profile
scope) - although a redirect is not always possible, or is frowned
upon from a design perspective (users' experience is broken since
they are taken to a different location with a different design).
Desired scenario:
user clicks on manage profile
user is redirected to a profile page on the client itself (e.g. SPA or desktop), populated with info from the profile scope
user updates profile data, and client then makes an API call to IdentityServer to update the users' claims centrally
local claims are refreshed to reflect claims sent to Identity Server
Main concern: is this a sound approach architecturally speaking? Should user profiles (e.g. first/last name, gender, DoB, etc...) be managed by IdentityServer (via an API or own pages) or should these be stored centrally and used/managed by both IdentityServer (loaded as claims) and individual client apps? How would you go about tackling the desired scenario?
The closest info I got was in method 3 discussed here.
... however it's a 3+ year old doc, and am not sure what is recommended by oidc-client/IdentityServer 4 devs today.
Any insights would be highly appreciated.
Chris
I believe the main reason for the need of the second scenario could possibly be
taken to a different location with different design
Is it?
If it's not, I don't see any benefit from repeating the same or similar claim update page on multiple client apps, if there are more than one.
If it is and you can't customize the page on your identity provider (the Identity Server), you can still have a single claim update page but just hosted outside of the Identity Server. This page (formally: the app that hosts it) would be the client of the identity provider as well as the client app that redirects here.
A benefit of this approach is that you could have a total control of how this page looks like, event make it conditional depending on the client.
Should user profiles (e.g. first/last name, gender, DoB, etc...) be managed by IdentityServer (via an API or own pages) or should these be stored centrally and used/managed by both IdentityServe
There is no single answer to this as it totally depends on you actual business background.
It's even worse than you describe, you can have a hybrid system where some claims are shared by multiple subsystems but other subsystems have their own profiles not shared with any other subsystems and all these are integrated around one identity provider.
I am new to Identity server but I found it quite easy to set up.
Our goal is to implement SSO down the line but at the moment we are just moving our authentication logic out of application.
It is going good except I have one confusion.
When I set up the Idsrv, I had to create admin user as well as token requesting user. This was to access and configure Idsrv.
For application auth, I have to use Idsrv as federation server as well and authenticate users against some Asp.Net data store.
Now there is already one data store where Identity server specific users are stored.
Should I be using same store for my application user auth and created/edit these users in that store? Or can I/should I create a separate database for application specific users and use both?
At the minute, I am authenticating application users against Idsrv store.
I am not sure if I am logically thinking in right way to split these two user sets and calling one as Idsrv specific users. (We will have Identity service separately deployed for each application)
Thanks for your help in advance.
I've been playing around with ASP.NET Application Services. I've implemented the Authentication Service, Profile Service and Role Service successfully, able to log in and get Profile information for the logged in user and Role information.
Now I've noticed a major shortfall in the fact that I can't work out how to create a new user account with the Application Services stuff. Does anybody know how?
Seems like the Application Services AuthenticationService only supports validating existing users. You should enable creating users through some other part of your application, either your own web service or a web page.
I'm not sure about Application Services, but I know that you can create new users with Membership Services.
That's like this:
Dim mbmr As MembershipUser
mbmr = Membership.CreateUser(newUserName,newUserPwd)
There are something like 6 overrides for the CreateUser method.
I think not many people are not fully understanding the role of application services and thus feel frustrated when they do not find the full asp.net provider stack exposed over a store bought json endpoint......
Application services are exposed publicly. They are meant to provide an authentication and identification facility.
Think...
Your user is not logged in. To log in you must access application services to authenticate.
Right?
Do you really think that exposing membership management api such as Create/Delete user on that endpoint is wise?
Exposing management functions on a public facing api presents a huge challenge to get right for ONE scenario, much less to capably facilitate every scenario so perhaps you can see why application services exposes only what you need to do identify and authenticate a user.