i have a asp.net web app in which i take system logon name and grant him access if the user is a member of a particular AD group(PrimeMembers)
Now we have moved the authentication code to a WCF Service(IsPrimeMember), and we got another WCF Service(GetProfiles) which calls IsPrimeMember before providing data
Now the question, If i would have called the IsPrimeMember service in my asp.net app I can safely get Logon ID from HttpContext.Current.User.Identity.Name.ToString and would not be tampered.
But when i provide the service via URL and open to a group of memmbers members may try to get access by trying different combinations of logon ID's as querystring.
One thing is we can provide some Key(like Private Key) as ask them to pass along with URL.
any other thoughts how this can be achieved
Related
I am very new to the concepts of SSO and Keycloak. I am trying to read the official documentation of Keycloak. In the "Supported Protocols" part (https://www.keycloak.org/docs/latest/securing_apps/index.html), the documentation talks about the two use cases of using OIDC like this:
"The first is an application that asks the Keycloak server to authenticate a user for them. After a successful login, the application will receive an identity token and an access token. The identity token contains information about the user such as username, email, and other profile information. The access token is digitally signed by the realm and contains access information (like user role mappings) that the application can use to determine what resources the user is allowed to access on the application.
The second type of use cases is that of a client that wants to gain access to remote services. In this case, the client asks Keycloak to obtain an access token it can use to invoke on other remote services on behalf of the user. Keycloak authenticates the user then asks the user for consent to grant access to the client requesting it. The client then receives the access token. This access token is digitally signed by the realm. The client can make REST invocations on remote services using this access token. The REST service extracts the access token, verifies the signature of the token, then decides based on access information within the token whether or not to process the request."
What I do not understand is this: In the first paragraph it talks about an application making a request and in the second one it talks about a client. But aren't applications counted as clients? Why the specific differentiation? And can anyone given an example of the remote services that is talked about in the second part?
Thank you.
But aren't applications counted as clients? Why the specific differentiation? And can anyone given an example of the remote services that is talked about in the second part?
Yes exactly it. The reason for the differentiation is because there could be many applications more than just this one client. And the client, that the user is authed against may want to access all those other applications' data.
For example take the google ecosystem. Does google email have access to drive, and photos, etc... While it could out the box, it doesn't. You need to explicitly allow email "offline access" to those other applications, even though they are all part of the same platform.
Keycloak understands this and provides that terminology. But it is a bit confusing because this isn't the best way to think about it. Instead a better explanation is that there is just the user and service clients. The service clients all talk to each other and ask for a user's data. While a user may want their data by going straight to one application, other applications may want that user's data too.
Assuming you want to actually allow one service to ask for user data from another service, you want to be using something that supports authorization as a service and not just authentication. There are some examples of this, such as PolicyServer and Authress.
I'm currently working to develop a companion web application to a main web app. The main web app has a regular ASP.Net identity provider, which I have full access to and can create endpoints against.
I want to use just the username/password combo from the main application to Authenticate my users. The new secondary app will have provisions to authorize and maintain the users once they've been authenticated.
I imagine a sencario where a person enters the creds into the secondary app and it's sent to the primary endpoint. Primary then responds with a CanLogin and IsAuthorized flags. The secondary app then lets the person in and they can from there request further authorization to the system to be approved first by admins.
I've read over and over the ASP.Net Core documentation and I think something claims based is what I want. I just don't know at what point in the middleware I catch the authenticating method in order to check the primary?
I have two different client apps written in javascript connecting to two different web api. I am trying to implement identity server 3.
Is it possible to have identity server behind my web api owin
authentication api end point. In other words, is it possible to
route /token endpoint from owin in web api to call /authenticate
endpoint in identity server?
Is it possible to audit log to db in identity server including
failed request along with user's ip and browser agent. Also is it
possible to log user's ip even if i am calling from web api as my
web api is being called by a user using browser?
In my case should i keep two different user base for two different
projects or move all my users to identityserver. If i move all the
user info to identityserver, how am i going to handle all the joins
with other tables in different applications or should i keep a copy
of user with minimum info such as id, email and name?
It makes little sense to first call a web api and deal with authentication during that call.
Your client apps should first redirect the browser to IdentityServer where user would log in and be redirected back to your client app along with either access token (implicit flow) or authorization code (AuthorizationCode flow), depending on the client app having a back-end or not. Then, your client app would make requests to the webapi, passing the access token in the Authorization header.
As for different user bases, one approach might be to implement specific IUserService for each user base and either send a hint about which one to use in the acr_values or tie it to specific clients registered in IdentityService. Again, depending on the requirements.
Is it possible to have identity server behind my web api owin authentication api end point. In other words, is it possible to route /token endpoint from owin in web api to call /authenticate endpoint in identity server?
Yes and no - you cannot reroute those requests, but you can host identityserver in the same application as a web api. In Startup.cs, map a folder to identityserver.
It's not a good idea to do this, first of all, which api of the two will host idsrv? What if that api goes down and takes idsrv with, then the other api does not work anymore.
-> host idsrv separately, make both apis and both javascript apps clients in idsrv, login to idsrv from the javascript apps (=SSO) and use bearer tokens for the api
Is it possible to audit log to db in identity server including failed request along with user's ip and browser agent. Also is it possible to log user's ip even if i am calling from web api as my web api is being called by a user using browser?
Yes, this should be possible, check the logging implementation for idsrv, at the least you should be able to plug in a provider that writes to a database.
In my case should i keep two different user base for two different projects or move all my users to identityserver. If i move all the user info to identityserver, how am i going to handle all the joins with other tables in different applications or should i keep a copy of user with minimum info such as id, email and name?
Idsrv does not need to have all the user info, just an email-address is enough, you can use that as link to the user data in your api databases if you use that as unique identifier.
I am trying to access the IBM Domino Access Services 9.0.1, which is REST based service for accessing all calendar items.
Lets say for getting calendar items for a user , i have to pass credentials of that particular user.
I don't think it is feasible to store the user credentials in the client side and pass the same while accessing those service instead will create one service account in domino server and access the service using the same service account.
Any idea how to configure in the domino side or how can i achieve accessing the calendar service without passing the credentials of the user.
Looking for similar to what we have are having like Exchange impersonation.
Thanks
Anil
It depends on what kind of application you are building. If each Notes calendar owner logs in to your application directly, it is possible to store the user credentials on the client side. Of course, your application would be responsible for securely managing the credentials. On the other hand, your application might require access to each calendar without directly involving the calendar owner. This can be the case for server-side applications.
Your question doesn't specify, so I'll assume yours is the second situation. In that case, you could create a user identity for your application and then add that identity to the Access Control List (ACL) for each mail file. There are two ways to modify the ACL: 1) You can change the design of the master template and let the design propagate to individual mail files, or 2) You can ask each user to delegate access to your application's identity.
The bottom line is the Domino calendar service acts on behalf of the authenticated web user. If that's the calendar owner, the calendar service will have full access to the calendar. If the web user is some other identity, access will be limited to the rights granted in the ACL. For more information about the ACL see this tutorial.
I need to propagate the Windows Identity of the current user across two service calls.
Service A (which runs under integrated authentication) calls Service B (which also runs under integrated authentication). I need to identify the user identity which was used to call Service A in Service B's code.
I know this is possible using delegation, by impersonating the User in Service A code and then call Service B from the impersonated code.
However, I only want to flow the identity and not impersonate the user. Is this possible without impersonation?
get the authenticated user using ServiceSecurityontext.Current.PrimaryIdentity.Name
Add this as either a header or a field in the downstream service request
I think you are looking for the impersonation level called "Identity". See this article for a description of different impersonation levels in WCF.