Remember me functionality in IBM Worklight [closed] - ibm-mobilefirst

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
We are using Worklight 6.1 for our app. I want the app to remember the user id (with no limitation on the duration & it should be accurate & reliable).I want to use JSONStore API for this purpose.
In our app, after we gather the user credentials, we are sending them
to an adaptor function, where we are invoking some java classes to
validate the credentials aginst IBM bluepages & also against dbs
I have two questions:
1) When i ensure that user has been authenticated successfully for the first time, I will open a JSON store & keep the userid to the local storage, If I choose to encrypt it , which password I need to supply to make it encrypted ?
2) When the user tries to access the app from the same mobile device, the server should send a login form by pre populating the user id, how do I do this?
Thanks..

Encrypted Offline Cache is deprecated, so you might as well use JSONStore.
In MobileFirst Platform 6.3 ("Worklight"), there is a tutorial that accomplishes exactly your scenario. You should read it and try to implement it in 6.1; depending on JSONStore's featureset in 6.1, you might be able to. You'll need to try.
Here it is: Offline Authentication

Related

linkedin "this application is not allowed to create application tokens" [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
My main problem is getting the token. I can’t go further than this step.
In the Linkedin API's docs there are two ways described to obtain the token.
Witch is the correct one?
1) https://developer.linkedin.com/docs/v2/oauth2-client-credentials-flow
2) https://developer.linkedin.com/docs/oauth2#configure
I understand that in order to use the new Linkedin API (the partners one) I should use the first one (https://developer.linkedin.com/docs/v2/oauth2-client-credentials-flow)
Here is my petition:
https://www.linkedin.com/oauth/v2/accessToken?grant_type=client_credentials&client_id={MYCLIENTID}&client_secret={MYCLIENTSECRET}
The response:
Error "access_denied"
error_description "This application is not allowed to create application tokens"
And I get stuck here.
With the second one (https://developer.linkedin.com/docs/oauth2#configure) I actually get a token:
https://www.linkedin.com/oauth/v2/authorization?response_type=code&client_id={MYCLIENTID}&redirect_uri={MYURIREDIRECT}&state={STATERETURNED}
This returns the code (and the State) which I use to make the token request:
https://www.linkedin.com/oauth/v2/accessToken?grant_type=authorization_code&client_id={MYCLIENTID}&client_secret={MYCLIENTSECRET}&redirect_uri={MYURIREDIRECT}&code={CODERETURNED}
And I get the token. But this isn’t the correct way to do it, is it?
By default you will need to use the authorization_code flow to obtain an access token. Per the documentation the client_credentials flow is not enabled by default and needs to be specially enabled by LinkedIn.
https://developer.linkedin.com/docs/v2/oauth2-client-credentials-flow

Mobile backend security / Securing an API [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I´m currently designing a mobile application, and I´m having some concerns about securing the backend which runs the services for it to run.
My current planning is, using SSL and a basic workflow like this:
The generated token expires, because it assures that if someone physically access the phone/device, he cant be in control of the user account for too long, but, at the same time, I don't know what duration is appropriated for it, as I don't want to keep asking for credentials every day.
My questions are:
Is this a good aproach? Would you add something else to it?
Whats the ideal duration of tokens when working on mobile apps?
First thing first, you should encrypt session key when you store it on device. For example, use shared preferences with encrypt option. Further info : Android SharedPreference security
Second, you may want to implement "SSL pinning" mechanism. Which means that verify SSL certificates at client side. You must be sure about that received certificate is belongs to your backend or not. So you can protect your backend URLs and parameters with that way. Further info : https://www.infinum.co/the-capsized-eight/articles/securing-mobile-banking-on-android-with-ssl-certificate-pinning or http://www.thoughtcrime.org/blog/authenticity-is-broken-in-ssl-but-your-app-ha/
Third, your design is good. But be sure about your session key generation mechanism is not vulnerability against "Session Prediction" attacks. https://www.owasp.org/index.php/Session_Prediction

How do I get rid of authentication login dialog when opening MS Office docs from a WebDAV server? [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 8 years ago.
Improve this question
I have an IT Hit WebDAV server which is using Basic+SSL. Each time I open MS Office document the login dialog pops up. How do I make it to be displayed only during first access and not shown each next time?
Microsoft Office applications always ask for the authentication when used with Basic or Digest authentication. This is a Microsoft Office and Microsoft Mini-redirector limitation and there are no workaround in case your server is using Basic or Digest.
However, if you check "Remember my password" check-box it will still display the login dialog, but the user name and password will be already filled-in, so you just click "OK".
Here are some options to consider if you need to totally suppress login dialog with Microsoft Office:
Use NTLM or Kerberos authentication. In case of NTLM or Kerberos MS Office asks for credentials only 1 time during first document access.
Implement Office Forms Based Authentication Protocol (MS-OFBA).
Implement Url-authentiation. Your urls will look like:
http://webdavserver.com/[SessionID1234567890]/path/file.docx
Make sure you do not include the session ID in query string, Microsoft Office will truncate it. You will have to put session ID somewhere in the path, as in the above example, which is not very convenient, when you need to mount a WebDAV folder in you file system, but still works in most cases.

Go, basic access authentication [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 1 year ago.
Improve this question
Does Google Go support decoding of basic access authentication calls? How do I get the username and password from the http.Request?
Go does not seem to intercept basic authentication when it is typed as an URL in a browser, but it does allow one to get it from some other applications calling it.
For example, using a simple Python code for HTTP JSON RPC:
from jsonrpc import ServiceProxy
access = ServiceProxy("http://user:pass#127.0.0.1:8080/")
print access.getinfo()
And in Go calling:
// r *http.Request
r.Header["Authorization"]
One gets this string:
[Basic dXNlcjpwYXNz]
And
dXNlcjpwYXNz
Base-64 decoded gives
user:pass
So some basic authentication in Go is possible, although it might not be something one can rely on.
There seems to be no way to get the user-provided authentication info, but you can provide the valid username and password for HTTP Basic Authentication by calling SetBasicAuth.

ASP - Biometric Authentication [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed last year.
Improve this question
Cheers,
We started implementing biometrics authentication in our web system and came to a doubt. We're going to use a third-party solution for performing it which is going to be called via a web service.
There are going to be four kinds of authentication:
Regular one: username/password
Challenge
Fingerprint
Cellphone
All users will be authenticated using 1. Optionally, some of them may also require 2, 3 or 4. What would be a good way of verifying which authentication type is required for a specific user?
This is something new for me. Initially, I thought about passing the username from the login page to a web service, which would query the database to check which authentication type is required for this user. Then, depending on the result, the second authentication form would be shown on the screen. Obviously, some extra check would be performed after the user hit the Submit button.
Am I on the right path, or there are better solutions for this?
Thanks,
I guess that would work. Maybe it is an option to do some sort of query in the background (AJAX?) when the username is filled in, so you can dynamically add extra inputs to your login form.
However, this has one potential issue: everybody that knows someone 's username can find out what authentication is required. If that is not wat you want, maybe just ask for a username + password to login to a reduced privelege mode. Then, as you suggested in your question, this reduced privelege mode may require extra credentials to continue to the more secure environment.
You could even make it so the reduced privelege mode will grant access to some of the features, while others require extra authentication (for example: posting a mesage would require basic auth, changing passwords might require all four).