I'am creating application which can be used by unknown and logged in users. Only difference is that logged in user can use some additional functions like saving its content in database.
All communication is based on ajax calls, so what I need is to deny access to some controller functions (end points) in backend for unknown users and on the client side I need to know that it is in logged in state to set this extra functions active. Only one page, login form should be in dialog. I'm little bit confused, because standard Spring Security aproach doesn't fit this case. I was reading this tutorial but I cant't fully understand it.
First: What Principal object does? They send credentials to this endpoint on submit with login() function but where is handled password check? What if I have my users in database?
Second Is it possible to write this configuration in XML style? I guess that it can be done with <intercept-url/> in spring-security.xml file.
Principal Object
The Principal Object is used to be able to get basic information about a user that is attempting to login when using automatic server authentication (i.e. LDAP). However, you will only be able to get a username from the principal object. With a server JBoss/WildFly, for example, you can link the server to Active Directory to allow Microsoft Windows to authenticate users.
Simple Solution
First, Spring Security will add additional complexity to your application where it doesn't sound like you are trying to do that. Instead, use a simple Servlet Filter. If you are using LDAP on a JBoss/WildFly sever, you can make a POST to j_security_check and the server will send the request to the filter if correct credentials are provided. Inside the filter, you may use the getName() function of the Principal object to get the username so that you may store it in the user's session. However, if you are not using LDAP, you may make a simple POST to a Java Servlet or Spring Controller (with an #RequestMapping) to attempt to login the user and store the user's information in the session.
At this point, you can filter out what URLs you will allow users to see. For example, the URL that contains /administrator/some/other/stuff.jsp could be restricted if the URL contains the word "administrator" in the first directory of the URL.
Related
Currently, I'm trying to access Graph API from within a (Standard) Logic App to search for Sharepoint documents. To do so, I try using the following flow (I need delegated permissions, application permissions cannot use search endpoint):
https://techcommunity.microsoft.com/t5/integrations-on-azure-blog/calling-graph-api-from-azure-logic-apps-using-delegated/ba-p/1997666
As one can see in the blog post above, there is a step where the following string gets passed into the body of the first request to get an access token for a delegated user:
grant_type=password&resource=https://graph.microsoft.com&client_id=client_id&username=serviceaccountusername&password=serviceaccountpassword&client_secret=clientsecret
Now the client secret and service account password are two things which I absolutely don't want to have visible in the Logic App code and/or designer screen. Is there a way to securely read these from for instance the 'app settings' (in which I could reference them from a KeyVault)? I really can't find a good way on how to achieve this and I think it's a must to not be able to read these secrets/passwords from the Designer/code view.
Definitely use a KeyVault and make sure that for all steps involved, secure the inputs/outputs where ever that secret information may be visible.
The below example is the call to get the secret and therefore, I only want the outputs to be secured.
Result
With your HTTP call, it's likely that you'll only want the inputs to be secured.
Be sure to use a managed identity on your LogicApp and then assign that managed identity to the KeyVault Secrets User role on the KV itself.
There's plenty of documentation on this topic ...
https://learn.microsoft.com/en-us/azure/logic-apps/create-managed-service-identity?tabs=consumption
I am creating an electron application that connects to an Database and do POST and GET requests to retrieve and insert data into it, the problem is that in the code i have defined my database uri ( im using mongodb)
const uri = "mongodb+srv://<myusesrname>:<mypassword>#cluster0.wqbiu.mongodb.net/query?retryWrites=true&w=majority"
like in the example above, but if i pack my electron app the connection to the database as well as the credentials its visible if someone unpacks the app.asar file and look in the server.js file how i can solve this problem? i dont want any security breaches neither for me or the people that will be using my application, thanks in advance for any answer :)
An application that requires a secure connection to something cannot afford to have any username's or password's hardcoded into its code.
Instead, a procedure of authentication and authorisation is utilised.
Authentication is used to verify the user. IE: They are who they say they are, often achieved via the use of some type of login form.
Authorisation is used to verify the logged-in user is allowed to access the requested resource. EG: Is this user allowed to retrieve a list of all users email addresses from the database.
As a rough guide, a user will login with their username and password. You could use OpenID as well here if you wanted. Once the user is 'logged-in' you could set a cookie or session and save the session id in the DB against the user. Of course, all of this is done over HTTPS.
There are various ways to control the validity of the session such as but not limited to refreshing the expiration date / time every time the user hits the server, auto timeout if the user has not interacted with the server for more than X minutes, etc.
In your app, the user could try and interact with the database at any time, but if the user is not logged in, the server could return the appropriate response and prompt the user to login. Some form of API here is really the way to go.
If the user is logged in then then next step is to authorise the users request, ensuring they are allowed to perform what they are asking before sending a response back. If they are not authorised to access the resource (EG: Edit another user’s post) then an appropriate response is returned indicating so.
As you can see, securing your app will take some work but the result of not doing so could be devastating to you and your users.
I need to set up Shibboleth IdP to validate user name and password against a custom application.
Our application exposes a REST API to which one can pass a user's credentials and either returns a 401 on failure or a JSON object with some user metadata on success.
I was able to achieve this in SimpleSamlPHP IdP with a 30-line class, but having to switch to Shibboleth, I am having a hard time finding directions to do the same there.
Reading through the documentation the suggested solution seems to be to create a custom back end for the password login flow but the Wiki does not explain in detail how to do this.
Can somebody point me out to some tutorials or sample code on which files need to be created or changed in order to do this (even basic examples of checking against a credential file or database would be fine)?
You are looking for an [External Authentication Flow] (https://wiki.shibboleth.net/confluence/display/IDP30/ExternalAuthnConfiguration)
For an example, see the shib-cas-authn3 project (https://github.com/Unicon/shib-cas-authn3). It uses the CAS Server to authenticate the users. It then creates an IdP session from information retrieved from CAS.
I am creating an Angular application, and I am having trouble wrapping my head around the proper way to ensure my application and its users is secure.
I've been reading around many stack discussions, but I believe I am missing some core understanding of what is happening, please correct any errors you see written below.
So far I have a Sinatra server with many (currently mostly hypothetical) resource routes. A user can create an account using an email address and password that is stored in a database after being hashed with BCrypt. When a user logs in, the record is retrieved from the database by email and the password checked for authentication. It is from this point I am not sure how to proceed.
Prior to this I have simply set a session variable and had the server check that the variable exists in order to correctly route logged in users. Now my application is (currently) a single HTML page that uses Angular and ui-router to display different content, so most of the requests are simply returning JSON content.
It is my understanding that Restful applications should generally not use sessions, or rather that the server should respond identically to identical requests and not have its own data that shapes a response. But if I do not store something in a session variable, how could the server know that the client making the request has the correct permissions? And are sessions not stored in the browser anyway, thus not part of the server?
I believe from what I have read, it is possible to create a token which is essentially a large random string, return that string to the client and also store it in a database with a timestamp. The client then provides this token when making requests and the server hits the database to verify it exists and valid. But would the client not also have to store that string in a cookie? I suppose the angular application could store the token in a variable, which would persist while using the ui-router but not if the users navigates using the address bar.
I also do not understand how Basic Auth may or may not fit into this picture. Any help would be greatly appreciated, as well as a pointer to some good resources where I may find a better understanding of these concepts in general.
You want to read up on JWT. There are JWT libraries for Ruby and Angular.
I know you aren't using Node for your backend but a very easy way to see all the pieces working together is to run the angular-fullstack Yeoman generator. It uses JWT and the code is easy to follow.
As far as I can see, whatever you are doing with your sessions can work just fine.
This can be a sample JSON response from the server in case the user is not loged in :
{
"errorCode": 1,
"error": "User not logged in",
"data": {}
}
You can set your own error codes and handle what you want to do. You will send any data only if the user is logged in. For all the pages which don't require authentication, you can set data to whatever you want.
On the angularJS side, you can handle based on error codes, you can redirect the user to the login page and so forth.
The alternate way to support the same on multiple platforms is to use token based approach. The token based approach in simple words work this way.
The user logs in for the first time with his / her credentials.
The server verifies these information and creates a token from which the server is able to decode the user id.
Whenever the client makes the requests, it passes its token with every request.
As the server can decode the user information from the token, it sends or doesn't send the data based on whether that's a right token or not.
The token depends on a secret value. It can be same for all the users or differnet for each based on how you want to implement.
This is all done and you can look at
http://jwt.io/
As #andy-gaskell mentioned, you can look at
http://angular-tips.com/blog/2014/05/json-web-tokens-introduction/
I'm very bad at explaining. Please let me know if any of this doesn't make sense.
you are missing the point of the REST concept. One of the main concepts in the REST apis is that the server should be stateless - this means that you should not store sessions or other "state" in your web server. Every HTTP request happens in complete isolation. Every request should include all data needed by the server to fulfill the request.
But if I do not store something in a session variable, how could the
server know that the client making the request has the correct
permissions?
You can store request scoped variables. This means that they should be only active during the same request. You can store the current logged in user in the request scoped variable. In that way you can get the current user in your invocation of the business method. I'm not familiar with Sinatra but here is the doc: http://www.sinatrarb.com/intro.html#Request/Instance%20Scope
But would the client not also have to store that string in a cookie?
of course you should store your access token in the client side
https://stormpath.com/blog/where-to-store-your-jwts-cookies-vs-html5-web-storage/
as #Andy Gaskell suggest take a look at JWT and fullstack application code generators and forget about the basic auth because it's really "basic".
more useful links:
If REST applications are supposed to be stateless, how do you manage sessions?
http://www.sitepoint.com/php-authorization-jwt-json-web-tokens/
I'm trying to figure out CakePHP cookies and meet my slightly unusual authentication requirements.
I have a CakePHP-based data collection system that is now being integrated with a reporting system built with COTS software. The reporting system needs to be access controlled and unless I want to duplicate all user accounts in both systems I need the reporting system to be able to find out if the user is authenticated in my CakePHP system.
The reporting system permits me to load a Java class and execute a function when the client's report request first arrives. So my idea was to
Inspect the incoming report request and extract the cookie used by my CakePHP site for authentication / session identification
Send a request from the Java function to a 'reportauth' action within the CakePHP site with this cookie attached
The reportauth action within CakePHP then checks if the user is logged in to the CakePHP site and returns an encrypted response to the Java function identifying the user's role
I can get the cookie, send it in a request, and separately I can share encrypted information between PHP and Java.
However, when I use a 'fresh' cookie (the cookie that my browser repeatedly sends with requests to the CakePHP site after a new login) in my Java request the response says the user is not logged-in. If I then reload the site in my browser I have been logged-out. I suspect that there may be some extra information in the cookie about user-agent (?) that causes the Java-sourced request to be thrown out and that session destroyed for safety, but I don't know the system well enough. I think I might be seeing CakePHP protecting against session hijacking (which, ordinarily, would make me happy).
Can anyone tell me if there is a way around this issue? Preferably one that doesn't involve custom auth components in CakePHP as the data collection site is already live and my reporting deadline is not far away.
Any help much appreciated.
One workaround:
Get CakePHP to store a random token in a separate cookie, and as a field in the user table.
Then get the Java application to grab the token, and send it to the cakephp application to get the user's details.
Alternatively, have it authenticate with the CakePHP app itself, and pass in the session id to have cake use the right session. Note, setting with that function needs to be done before session_start() is called.