I am implementing a Login page with AngularJS to authenticate against LDAP server. The authentication at the back end is done by Spring Security. Basically username and password are sent to server via a post request which is handled by Spring without an explicit handler.
When I submit the login form, the post request returns 302 and redirect to another url based on whether credentials are valid or not. If the password is correct, it will initiate GET request to "http://localhost:8080/". If password is wrong, it redirects to "http://localhost:8080/login?error". This is known behavior of Spring Security. According to Dave Syer's article, "the Spring Security default behaviour is to send a 302 on success and failure, and Angular will follow the redirect, so we would have to actually parse the response from that". In Dave's tutorial, he used a helper function to verify the authentication in the general case. I don't think it would work for LDAP authentication though.
I found another very similar post Spring Boot and Security with custom AngularJS Login page. Although it does not have an official answer, based on the last comment, it seems modifying paths in .antMatchers in Java config may have resolved the issue. However I played with my security config (see below) back and forth and it did not seem to help.
protected void configure(HttpSecurity http) throws Exception {
http
.httpBasic().and()
.addFilterBefore(new CORSFilter(), ChannelProcessingFilter.class)
.csrf().disable()
.authorizeRequests()
.antMatchers("/login/", "/login","login/")
.permitAll()
.anyRequest()
.authenticated()
.and()
.formLogin();
}
Although 302 does not produce any response, client somehow knows which url to redirect to based on credential's validity. My understanding is that the server must have told client if authentication succeeds or not in a "secret" way. If I capture and parse this hidden information before client sends GET request, I could make the authentication work with Angular. Something like this (partially pseudo code):
app.controller("LoginCtrl", ['$scope', '$location',
function($scope, $location){
$scope.authenticate = function() {
loginFactory.login($scope.username, $scope.password) {
// pseudo code starts
if (redirect.path == 'localhost') {
$location.path('/main');
}
else {
$location.path('/loginfail');
console.log("Login failed");
}
}
}]);
The question is how to diagnose the 302 and identify the nature of the response before redirect happens? Worst case scenario, I could let the redirect to start, and grab response.path from the GET request and decide whether login is successful. But I try not to go down that path. Need suggestion badly.
After hours of google search, I found a way to suppress the 302 and thus avoid redirects based on this article. The resolution is to inject a custom authentication success handler in the form login filter and SimpleUrlAuthenticationFailureHandler to handle failed authentication.
Related
I am making Rest calls to Springboot controllers and have security configuration which need authorization and roles for accessing certain URL.
http.authorizeRequests()
.antMatchers("/api/admin/**").access("hasRole('Admin')") //
.antMatchers("/api/user/**").hasAnyRole("Admin","User")
//.antMatchers("/api/user/**").access("hasRole('User')")
//.and().logout()
.and().formLogin()
.loginPage("/login").usernameParameter("userName").passwordParameter("password")
Now the issue is when i gets logout from Spring controller side (like application restarted OR timeout etc), when User gets this call, it returned me whole login page UI. I want Spring to return me some status code and some message saying that session time out OR something which i can get user to call logout.
So i was able to sort the things in traditional way as Spring does not gives me any specific status code but 200 in this case.
I made an instanceof check in my AngularJS controller code like this-
if(response.data instanceof Object){
self.list = response.data;
}
else{
logout();
}
This solved my case. If there is better way, please comment.
I am creating custom skill in Alexa which uses account linking. I have created my own authentication server using OAuth2 php library and I have configured the authorization url and token urls in skill configuration.
When I try account linking from Alexa mobile app, I get error 'unable to link your skill'. following is my work progress.
Alexa app is able to open my authentication url.
I am able authorize and provide authorization code with redirect uri.
Alexa is requesting for access token using authorization code previously provided.
I am able validate authorization code and response back with access token and refresh token.
Alexa fails in this step to link with my skill. It say's 'Unable to link your skill'.
I have gone through my forums about the same, but couldn't find what exactly the issue is. Could any one please help me out in this regard.
I was facing the same issue too , the problem was solved by selecting "credentials in request body" (default being Http basic) for "Client Authentication Scheme", since the access token in my case was sent in the body of the message. Check how the authentication token is sent by your server.
If your redirect link is currently:
https://layla.amazon.com/api/skill/link/xxxxxxxxxxxxxx?code=xxxxxxxxx&state=xxxxx
You need to change the ? to a #
e.g.
https://layla.amazon.com/api/skill/link/xxxxxxxxxxxxxx#code=xxxxxxxxx&state=xxxxx
Thought this might help anyone wondering how the Alexa service is posting to their OAuth endpoint since it's pretty opaque and undocumented. The redirect to the Alexa service initiates a POST request to the defined OAuth endpoint with the post body in x-www-form-urlencoded format not JSON. So the POST looks like this.
POST /authentication/1/oauth HTTP/1.1 url.Values{} grant_type=authorization_code&code=XXXXXXXXXXXXXXXXXXXXXXXXX&redirect_uri=https%253A%252F%252Fpitangui.amazon.com%252Fapi%252Fskill%252Flink%252FM9BEOG3DM65SQ&client_id=XXXXXXXXXXXXXXXXXXXXXX
If your endpoint isn't parsing this data or expecting some format that can be unmarshaled easily then it is probably failing with a 406 response.
In my case the problem was with the Client secret,
In google developer console add your skill redirect URIs
and recheck the client secret you provide in the alexa skill Authorization grant type
My issue was with the final AccessToken call. I was assuming it was using a GET request, so I only catered for this in my function. It is actually creating an access token. So it's using a POST.
After I updated my function to use a post and return the AccessToken in JSON format it all works fine.
Maybe the following steps will help you identify the problem:
Add console.log('LOGS', response) to your Lambda function.
Activate the skill and login in the Alexa app
Go back to your Lambda function and check the last logs for the LOGS entry.
If you find that the Lambda function is invoked than the problem is not from your OAuth server, but you may need to handle the "AcceptGrant directive" in your Lambda function as it is motioned here: https://developer.amazon.com/en-US/docs/alexa/device-apis/alexa-authorization.html#directives
adjust your Lambda function to:
exports.handler = function (request, context) {
if (request.directive.header.namespace === 'Alexa.Authorization' && request.directive.header.name === 'AcceptGrant') {
log("DEBUG:", "Authorization request", JSON.stringify(request));
handleAcceptGrant(request, context);
}
function handleAcceptGrant(request, context) {
var response = {
event: {
header: {
"namespace": "Alexa.Authorization",
"name": "AcceptGrant.Response",
"messageId": request.directive.header.messageId,
"payloadVersion": "3"
},
payload: {}
}
};
log("DEBUG", "Alexa.Authorization ", JSON.stringify(response));
context.succeed(response);
}
If the problem is with the AcceptGrant then The account linking should be now successful.
I am developing a MEAN application. I am using passport for authentication- local, facebook and google strategies.
I am using angularjs client. All the routing is handled at client. I am only consuming server data apis.
When using passport-facebook strategy, I am using below code at node server as per passport docs.
app.get('/auth/facebook',passport.authenticate('facebook-auth', { scope : ['email'] }));
app.get('/auth/facebook/callback',passport.authenticate('facebook-auth', {
successRedirect : '/home',
failureRedirect : '/login',
scope:['email']
}));
Problem I am facing is when user click on "Sign in using Facebook" button
<i class="fa fa-facebook"></i> Sign in using Facebook
Client will access "/auth/facebook" route that will eventually redirect user to facebook page for validating user's credentials.
After successful validation, user will be redirected to route "/home" as defined in "successRedirect" value.
Now the thing is, I want to use custom callback function instead of defining redirects for success or failure. It will look like below:
app.get('/auth/facebook/callback',passport.authenticate('facebook-auth', function(err,user,info){
if(err){
throw err;
}
else if(user === 'userexists'){
res.json({
'state':false,
'message':'User with this e-mail already exists'
});
}
else{
req.logIn(user,function(loginErr){
if(loginErr){
throw loginErr;
}
res.json({
'state':true,
'message':'You logged in successfully!'
});
});
}
}));
The root problem I am facing here, I can not use above custom callback as Client is not calling the "auth/facebook/callback" route, it is called by facebook.
So, there is no success handler waiting to catch above callback's response at client side!!
I want some way to get response in json form at client to eliminate server side redirection and also way to pass message and username to client after successful authentication by facebook.
I am about to give up with passport. Hoping for any possible solution before removing a lot of code!
Thanks
This can be accomplished by redirecting to another endpoint inside the facebook callback handler. There is no need to do res.json() on the callback from facebook since they only make a request to that in order to let you know if auth failed or succeeded. From their docs:
// GET /auth/facebook/callback
// Use passport.authenticate() as route middleware to authenticate the
// request. If authentication fails, the user will be redirected back to the
// login page. Otherwise, the primary route function function will be called,
// which, in this example, will redirect the user to the home page.
So facebook returns control over request process back to you when they call /auth/fb/callback but it's up to you what to do next. Since once the user is successfully authenticated, you would have req.user available throughout the whole session. At this point, you can redirect to something like the have in the example /account and check if req.user with req.isAuthenticated() and complete the flow you desire.
I'm building a RESTful API with the Restlet framework and need it to work with cross domain calls (CORS) as well as basic authentication.
At the moment I'm using the CorsFilter which does the job of making my webservice support CORS requests. But, when I try to use this with a simple ChallengeAuthenticator with HTTP Basic Authentication it won't work as I want it to (from a web site).
When I access the webservice directly via Chrome it works as intended, but when I try it in a small web application written in angularjs (jquery/javascript) and try to access the webservice it does not.
Basically what happens is that when a OPTIONS request is sent to my webservice it will not respond with the headers: 'Access-Control-Allow-Origin', 'Access-Control-Allow-Credentials', etc. as it should. Instead it is sending a respond with HTTP status code 401 saying that the authentication failed.. Is this because the authenticator is overriding the CorsFilter somehow?
My createInboundRoot method can be seen below.
#Override
public Restlet createInboundRoot() {
ChallengeAuthenticator authenticator = createAuthenticator();
RoleAuthorizer authorizer = createRoleAuthorizer();
Router router = new Router(getContext());
router.attach("/items", ItemsServerResource.class);
router.attach("/items/", ItemsServerResource.class);
Router baseRouter = new Router(getContext());
authorizer.setNext(ItemServerResource.class);
authenticator.setNext(baseRouter);
baseRouter.attach("/items/{itemID}", authorizer);
baseRouter.attach("", router);
// router.attach("/items/{itemID}", ItemServerResource.class);
CorsFilter corsFilter = new CorsFilter(getContext());
corsFilter.setNext(authenticator);
corsFilter.setAllowedOrigins(new HashSet(Arrays.asList("*")));
corsFilter.setAllowedCredentials(true);
return corsFilter;
}
(The authorizer and authenticator code is taken from the "official" restlet guide for authorization and authentication)
I've tried alot of changes to my code but none which given me any luck. But I noticed that when setting the argument "optional" in ChallengeAuthenticator to true (which "Indicates if the authentication success is optional") the CorsFilter does its job, but obviously the ChallengeAuthenticator does not care about authenticating the client and lets anything use the protected resources..
Has anyone had a similar problem? Or have you solved this (CORS + Authentication in Restlet) in any other way?
Thanks in advance!
I think that it's a bug of the Restlet CORS filter. As a matter of fact, the filter uses the method afterHandle to set the CORS headers. See the source code: https://github.com/restlet/restlet-framework-java/blob/4e8f0414b4f5ea733fcc30dd19944fd1e104bf74/modules/org.restlet/src/org/restlet/engine/application/CorsFilter.java#L119.
This means that the CORS processing is done after executing the whole processing chain (authentication, ...). So if your authentication failed, you will have a status code 401. It's actually the case since CORS preflighted requests don't send authentication hints.
For more details about using CORS with Restlet, you could have a look at this link: https://templth.wordpress.com/2014/11/12/understanding-and-using-cors/. This can provide you a workaround until this bug was fixed in Restlet itself.
I opened an issue in Github for your problem: https://github.com/restlet/restlet-framework-java/issues/1019.
Hope it helps,
Thierry
The CorsService (in 2.3.1 coming tomorrow) contains also a skippingResourceForCorsOptions property, that answers directly the Options request without transmitting the request to the underlying filters and server resources.
I have several AngularJS apps all using Spring/Java and SAML 2.0 for SSO (leveraging the Spring Security SAML extension). My SSO id provider is OpenAM and everything is working pretty well. However, I am running into a situation when a user does a global logout from within one application but has other tabs open. Since these are single page web apps, a lot of functionality may still be usable in the orphaned tabs UNTIL, the user does something to invoke an ajax request. Of course, these AJAX requests get intercepted by the Spring Security SAML filters and triggers an authentication attempt via a REDIRECT to the OpenAM login URL. Of course, this wreaks havoc in the browser since redirects to another domain aren't allowed on AJAX requests. Furthermore, I can't really do anything with Angular's $http interceptors as the requests are 'canceled' and no quality information is available in the $http error callback function (such as a convenient 401/403 status code). All I know is that the request failed.
I don't want to assume that all bad $http requests are due to authentication problems (and do a $window.location.reload()) as there could be legitimate reasons for failure. My preference is to suppress the Spring Security redirect (to OpenAM login page) for ajax requests and, instead, send back a 401/403 status code. This would allow me to handle the error in the $http interceptor and do a full page load if it is an authentication failure, thus elegantly redirecting to the login page as if they were going to the site for the first time.
Any ideas for how to accomplish this?
The bean responsible for initialization of authentication and decision to return an HTTP error, perform a redirect, ... is an instance of AuthenticationEntryPoint. To change its behavior you can either:
customize the current SAMLEntryPoint (extend the commence method) and override the default behavior in case request is an AJAX call from Angular, so it returns an HTTP error instead of performing redirect to IDP
or define another security:http element in your Spring context (before the current one) which only covers your AJAX requests (e.g. with attribute pattern="/api/**") and uses an entry point which behaves in the way you want (see Http403ForbiddenEntryPoint)
Referring to a possible implementation of Vladimir's first bullet - taken from https://www.jasha.eu/blogposts/2015/10/saml-authentication-angularjs-spring-security.html
public class XhrSamlEntryPoint extends SAMLEntryPoint {
#Override
public void commence(HttpServletRequest request, HttpServletResponse response,
AuthenticationException e) throws IOException, ServletException {
if (isXmlHttpRequest(request) && e instanceof InsufficientAuthenticationException) {
response.sendError(HttpServletResponse.SC_UNAUTHORIZED, e.getMessage());
return;
}
super.commence(request, response, e);
}
private boolean isXmlHttpRequest(HttpServletRequest request) {
return "XMLHttpRequest".equalsIgnoreCase(request.getHeader("X-Requested-With"));
}
}
Keep in mind that X-Requested-With is not a mandatory header so the detection is not bullet-proof according to this answer. In my case since the backend was used with a SPA frontend, I removed the check of ajax call altogether.