I have been trying to determine a good strategy for authentication between a single WPF application of which calls to Web API services.
The client WPF app should be the only application to ever call the Web API.
I think I do have some unique requirements I must abide by. For example, The boss does not want to use ssl in any way; he is paranoid of users may having to deal with certificates.
Like I said, the client application is the only client using the Web API. The API just calls a list of stored procedures on a separate server.
Currently, we have a user membership database that does not align with any membership db standard, but we currently have over 200,000 members. One of the stored procedures currently authenticates the user with the membership db. The client application requires valid users to sign in to the application at start-up, however, we are wanting to secure all of the Web API requests sent from client to prevent non-valid requests being made to the server and so to prevent.
We are concerned about using the individual accounts or local authentication to essentially authenticate every web API request because of the added cost.
I have been thinking that what we are really needed to do is pretty much authenticate that it is our software client(WPF application) making the request and this authentication could open up all the controllers and actions for requests made by the client rather than the user. The user and its authentication is somewhat separate and is in place to prevent unauthorized users on a particular machines install of the application.
So you must have a valid user account to use the application.
Any suggestion would be great. I am just asking to get pointed in the right direction. I am really new to security so all suggestion will be valuable to me.
Thanks.
Related
I'm creating the user authentication in a web application, and I want to use Identity Server for resource protection.
The sample code and documentation shows how the user logs into Identity Server after creating an account for it. That is to say, they log in with their own Identity Server account. The quickstart even provides a UI.
But I don't want users of my application to have to log in to Identity Server, an external website. I want them to only have to log in to the web application.
So how to proceed? It just doesn't seem at all clear from the documentation how you're supposed to handle this scenario, which I would have thought would be the most common.
Do I just use a pre-defined API scope and user for token validation, holding for all the website's users? That doesn't seem to be very secure given that any user of the website or anyone with the client name and secret would have a valid token. Not sure what the point is in having the security if it's that easily worked around.
Or do I interact with my Identity Server instance somehow after the user is registered in the web application, and store the new user in a database? I can't find any mention of this in the documentation . It all seems to be very muddled to be honest.
Please could anybody shed light on some of this? What is the "standard" approach here? To have the user sign in to the external Identity Server website? That seems a great way to annoy your users.
If you only have one application and you don't intend to add more applications that needs to share users, then you should look at ASP.NET Core Identity
The whole point with OpenID-Connect/IdentityServer is to delegate the managing and handling of users/passwords (authentication) to a central entity. So individual applications don't need to deal with that complexity. IdentityServer is useful when you have multiple applications or if you have more complex integration needs. It is also perfect if you need to customize it to your own needs. If you don't need the customization part you can also outsource it to someone else like Auth0 that give you an IdentityServer like experience as a service.
Im searching solution about authentication.
I found IdentityServer and Im trying understand how it works.
In my case I need to check user exist in another app.
I have old project created in asp.net web froms and this project have a users collection stored in db.
Now I must create client who will be call to WebApi and in this WebApi I need to authenticate user. I want to do this using IdentityServer4. Can I in IdentityServer call to my old application or db this application and check user by custom method?
In future I want connect another application to IdentityServer and this new application should have users in IdentityServer, so I will be have two places where I will have users for two application. I need to be sure I can check user exist in this two ways.
When request will be form new app IdentityServer should check user in his db and if request is from client who will be call to old app should check this user in external app(db).
Example call:
enter image description here
I dont know I good understand idea of IdentityServer, but generaly I think this is not good solution for my case...For now I understand I can store users in database but only with Asp.Identity in IdentityServer.
What do you think about this case ?
In future I want connect another application to IdentityServer and this new application should have users in IdentityServer, so I will be have two places where I will have users for two application. I need to be sure I can check user exist in this two ways.
When request will be from new app, IdentityServer should check user in his db and if request is from client who will be call to old app, should check this user in external app(db).
The short answer is that IdentityServer4 is just an implementation of the OpenID Connect protocol and the persistence and authentication of users is entirely customisable so you're free to implement that any way you like.
As for where to keep your users - that will depend on your problem domain and business rules but I'd probably try and avoid using multiple DBs if possible and instead migrate existing users from legacy applications to your identity service's own store and take care to only bring over identity and authentication information and not access control/authorization information. i.e. keep the authorization logic in your client applications and APIs.
One of our clients requested that we integrate our system with ADFS (Active Directory Federation Services) while another requested that we integrate with Okta. They want the experience to go something like this: the end users opens up the Windows app (on their domain joined computer) and is able to use it right away with implicit authentication from one of those identity providers. No extra clicking or registration. I am willing to create multiple copies of the application integrated into these different identity providers if necessary.
Our current setup uses Node/Express as a backend (hosted on amazon web services) and all traffic is sent through this API. Our client interface is a wpf Windows application. This seems to be a less common setup. Currently, the user must sign up with an email and password, and must log in using that same email and password to start using the application.
There are 3 parts to this question that I'm super confused about (I'm an intern with limited knowledge, so please explain like I'm 5 if possible). On the other hand, I believe I have a solid understanding of how Single Sign On conceptually works (with us being the service provider and ADFS/Okta being the identity provider). Even if you can answer parts of these questions, I would be super grateful!
What (if anything) do I have to do to our API backend? I'm assuming everything just needs to be done through the windows client right? But then I saw a passport saml package but I'm unsure if I need it to complete this task.
What do I have to do to our frontend? I've tried one of auth0's sample windows application but it seems like everything is still going through a login screen. At least for any social media connection. We'd like to ideally do this without a login screen and hopefully without proprietary software like Auth0 (since we manage our own user database already). We just want something so that at startup of our wpf application, the application queries for user's information (through ADFS or Okta) and then all behind the scenes, the user is logged in automatically. Any pointers here?
What I do have to do on the 'main' active directory Windows server side (this would be on a client's enterprise network)? I've seen hints of setting up callback urls, certificates, metadata, and something, but I'm unsure of what all of that is. Lots of questions just reference that but don't explain what or why it's needed?
Lastly, I apologize if any of the questions are vague, I have tried to do research, but it just seems like all the pieces are either too advanced or just don't apply to my setup. Thank you for your time!
ADFS etc. rely on federation protocols like WS-Fed and SAML 2.0 and so the IDP behavior is determined by the protocol.
There is no browser based functionality to just log you in.
You will always be taken to an IDP login screen. Once you have authenticated, other applications on the same IDP won't require authentication. They can seamlessly log you in based on cookies.
You can't query for user info. until you know who the user is.
On the ADFS side, you can manually configure a RP (your app).
We are planning to implement an AngularJS web application communicating with Business components via REST service layer. The web app needs to offer authentication mechanism.
For example we are particularly concerned by the user authentication process since Angular code is practically available to the users on their clients.
And how can we reassure that the users are authenticated after the initial authentication process (in JSP/PHP we would use sessions)?
Could you please give us some pros. and cons?
Your right client side code is available, viewable, and editable thru standard browser developer tools. If your company does any type of security audits on your software you'll find that for security reasons processing is done on server side outside of the view of the client code. The companies I have worked for have taken the approach to trust nothing that is sent from the client side to the server.
On the server side the REST layer typically contains a authentication layer that will bubble back to the client when.
-invalid session
-incorrect permissions to make rest call
-invalid REST args
-prevents script jacking into text fields
-etc...
When working with angular or other client side only applications, I recommend using Token based authentication.
A demo application in Angularjs
Token Based Application
Angular JS, Web API Token Based Authentication
I'm a complete newbie on the concepts of web security and I was having a pre-conceived notion that securing the application is incredibly hard.
Looking at a video on Apache shiro, I have a feeling that the complexity of security has all been abstracted in form of a nice, simple, unified API.
I'm trying to write a security layer which will be responsible for Authorization and SSO for my underlying SOAP based webservices.
The permissions will all be sourced from LDAP (OpenDS) which will be maintained on my side (ie not external), as they reflect the bunch of functionality available on my system.
I have a requirement that clients can have their user management in Active Directory (external) and once they log-in to AD (probably their windows login), they should automatically be authenticated to be able to consume my services.
Then I will check whether the user has got the right authorization to consume a specific service.
This effectively means, Authentication is done externally but authorisation is done internally as far as my boundaries are concerned. But my security layer has to understand that the user has been authenticated and know who the user is.
Is this achievable in Shiro? Any pointers would be of great help.