I am using Cas overlay approach. From time to time I get problems with getting into /cas/services/manage .
"
Access Denied
UsernameNotFoundException::aaa
"
Sometimes it actually lets me in. In deployerConfigContext.xml I have declared "aaa" user.
<sec:user-service id="userDetailsService">
<sec:user name="aaa" password="aaa" authorities="ROLE_ADMIN" />
</sec:user-service>
What can be causing this inconsistent behaviour?
excerpt from logs showing that authentication went ok
2013-07-31 11:53:05,332 INFO [org.jasig.cas.authentication.AuthenticationManagerImpl] - <org.jasig.cas.authentication.handler.support.SimpleTestUsernamePasswordAuthenticationHandler successfully authenticated [username: aaa]>
2013-07-31 11:53:05,333 INFO [org.jasig.cas.authentication.AuthenticationManagerImpl] - <Resolved principal aaa>
2013-07-31 11:53:05,333 INFO [org.jasig.cas.authentication.AuthenticationManagerImpl] - <org.jasig.cas.authentication.handler.support.SimpleTestUsernamePasswordAuthenticationHandler#4b4bc1e authenticated aaa with credential [username: aaa].>
This sounds like user aaa is not available in your Authentication Handler. The XML code you supplied just authorizes that user to use that service, it does not allow that user to authentication into CAS.
The inconsistency could be that your Authentication Handler (database/LDAP/in memory to name a few) is not available at the time of authentication.
Related
I am using WSO2 identity server(wso2is-km 5.7) for multifactor authentication for an application.
I have set policy as:
First time login to application: Basic Authentication + email OTP.
This sets a device cookie in the browser, so when I logout from the application and try to login to the same application again it should just ask me for basic authentication.
Second and further login to application:Basic authentication(no email otp this time).
This whole policy works fine when i am carrying out this activity from intranet(Corporate network) but the same doesn't work if I try to login from internet(we have put WSO2 behind WAF[web application firewall]). Here i am being prompted for email otp even on second and further login to the application, meaning the device cookie is not being correctly set here.
Please refer the error below:[ERROR]
Error occurred when converting cookie value to JSON.Unexpected token END OF FILE at position 993
My guess is the cookie being set in the internet case is not proper(appended with some garbage value during SSL offloading at WAF).
How do i reslove this issue??
In Redmine is possible to register new account using web interface via
http://redmine/account/register
When Submit is performed browser sends a POST to account\register with this data:
utf8=%E2%9C%93&authenticity_token=6XEpkFIoAsXyIvAk3j%xxxxxxxroM3yJm5yV4dLoExNg%3D&user%5Blogin%5D=myuser&user%5Bpassword%5D=password&user%5Bpassword_confirmation%5D=password&user%5Bfirstname%5D=firstname&user%5Blastname%5D=lastname&user%5Bmail%5D=test123%40mydomain.tld&user%5Blanguage%5D=it&commit=Invia
In logfile is possible to see:
Started POST "/account/register" for 173.102.44.73 at 2017-03-09 15:53:13 +0100
[...]
{
"utf8"=>"✓",
"authenticity_token"=>"long_alphanumeric_string",
"user"=>{
"login"=>"mynewuser",
"password"=>"[FILTERED]",
"password_confirmation"=>"[FILTERED]",
"firstname"=>"myfirstname",
"lastname"=>"mylastname",
"mail"=>"test123#mydomain.tld",
"language"=>"it"
},
"commit"=>"Invia"
}
Redmine has Rest API support but I can't find how to register a new user using JSON.
EDIT: Is it possible to create/register new user via JSON POST using http://redmine/users.json as described here but Administrators rights are needed.
Web interface permits account registration for anonymous users, is it also possible via Rest API ?
The following should work:
create a redmine api-user i.e. api-user-cancreateusers
enable REST API in Administration -> Settings -> Authentication
generate/get the api-user api-key
give the api-user rights to create users
put the api-user name and key into your program/service
profit!
redmine-auth-doc
Edit:
give the api-user rights to create users
as hinted in the comment - it seems there is no such thing. the only way seems to give the api user admin rights (shudder)
alternatively fetch the account/register page and replay with the provided auth_token
Here is the problem: I have a KB Called APP1 that will execute an WebService of an Identity Provider (centralizes all the logins/sessions for different applications) that will return true if there is a logged user in current WebSession that has been granted to access the Application or false otherwise. When I create an web panel at the same KB as the Identity Provider, it works just fine, I get TRUE when there's a logged user, and FALSE when there's not. But when I call it from APP1 it always returns false, I believe that the problem is because the WebSession won't work properly when called through an WS. Any ideas of how to solve it?
My first advice is to try using GAM Single Sign on (X Evolution 3)
WebServices should be Stateless. I think that using the Database instead of WebSession could do the job.
Nonetheless, in order to call a restful WebService you will have to do something more complex as dealing with CookieContainers as stated in the following link.
Consider this solution:
User tries to access App1
There's no web session (App1 doesn't know who is connecting)
App1 redirects User to an IdentityProvider's special login page
If User is not logged, it provides credentials and logs in
IdentityProvider has a session for the user (it knows who is connecting), then it redirects to the referer, appending to the url an encrypted userid parameter.
App1 decodes the parameter, now it knows who is connecting.
App1 saves the userid to the web session, now the user is authenticated
App1 and IdentityProvider must share an encryption key.
Consider that if the encryption key gets compromised or cracked anyone can impersonate another user.
Depending in how secure you want your system to be, you should study other security issues:
every time the user connects it's encrypted login is the same an it shows in the url, it can be easily solved adding a nonce or salt.
The system could be abused generating multiple requests until it gets a valid encrypted userid. It can be mitigated using a large Salt and/or blocking multiple attempts from the same source.
Note that this isn't a tested protocol and I didn't study the security in depth. I got some inspiration from OpenId, but this is a simplified protocol and I could be missing security holes.
Here is the params that I sent along with create shared link and got "Internal Server Error"
{"shared_link":{"access":"Collaborators","permissions":{"download": true}}}
This is a case of (1) bad documentation and (2) a bad error response.
You're seeing an error because the permissions parameter can only be used with the Open and Company access types*.
On (1) we should have this documented (I just updated our documentation to reflect this). On (2) we should be returning a more descriptive error (e.g. a 400 Bad Request and a message of " doesn't work with this access type. This is also in our development pipeline) "
*If you're really curious, it doesn't work with the Collaborators type because it's expected that the permissions set by the collaboration for each user will define their shared link access. Not the most straightforward thing, I understand.
What's the meaning of "error_subcode" in error information?
Can we make sure the error type by Analyzing "error" and "error_subcode"?
Do facebook has official explanation about the "error_subcode"?
As described in an old stub from Facebook
Along with a human-readable message, error responses include an error_subcode that describes the nature of the error. Although you can generally only respond to these errors by reauthenticating the user, you can use these subcodes for internal logging purposes or to better explain why you're asking the user to log in again. The possible codes and their meaning are below:
`error_subcode` Meaning
456 The session is malformed.
457 The session has an invalid origin.
458 The session is invalid, because the app is no longer installed.
459 The user has been checkpointed. The error_data will contain the URL the user needs to go to to clear the checkpoint.
460 The session is invalid likely because the user changed the password.
461 The session is invalid, because the user has reinstalled the app.
462 The session has a stale version.
463 The session has expired.
464 The session user is not confirmed.
465 The session user is invalid.
466 The session was explicitly invalidated through an API call.
467 The session is invalid, because the user logged out.
468 The session is invalid, because the user has not used the app for a long time.