We have a Spring MVC application hosted in Google App Engine. Now it has been integrated with Single Sign On using Spring-SAML Extension. After successful login, we are able to receive SAML response from idp. Now i have to capture the URL parameters passed by my initial URL.
Initial URL: (GET Request)
http://localhost:8080/spring-security-saml2-sample/download?filename=Culture%20Close-Up&Type=Word&order=1&name=jack&city=Seatle
invokes idp -> login
Response from idp after successful login (POST)
http://localhost:8080/spring-security-saml2-sample/saml/SSO
I am able to receive the response, but the initial parameter values passed in
(eg:name=jack) is not receivable. How to preserve the parameter values.
Thanks.
Related
We configured our SPA with mod_auth_mellon and the SP Initiated setup works well.
We now want to add the ability to dynamically route to SPA URL which initiated the SSO SAML call.
Below is the current flow
User opens the URL http://foo.com/user/1
Session is expired, so the SP initiates SSO handshake and redirects user to IDP (Ping Federate).
User logins on IDP and after successful authentication is redirect to http://foo.com/sso_callback
In Step(3) we now want to redirect back to http://foo.com/user/1.
What configuration changes should I make in SP / IDP configuration to enable dynamic routing?
If you are using SAML 2.0 then you want to use the RelayState. When creating your AuthN request in step 2, you will want to make sure that you as the Service Provider are including your desired RelayState. The value you provide to the IDP for RelayState will be carried through the transaction and given back to you as a URL parameter in Step 3 when the user POSTs to your ACS # http://foo.com/user
Here is an example flow:
User opens the URL http://foo.com/user/1
Session is expired, so the SP redirects the user to the IDP with an AuthN token AND a RelayState value of http://foo.com/user/1
IDP Authenticates user
IDP directs the user to POST a SAMLResponse token to the SP ACS # http://foo.com/sso_callback, and also includes an additional URL Parameter for RelayState
SP consumes and validates SAMLResponse at the ACS, and if successful then redirects the now active sessioned user to the value contained in the RelayState parameter
On the off chance you are not doing SP init SSO and are instead doing a generic redirect to an IDP initiated SSO Url from PingFederate, you can add the url parameter TargetResource to your IDP initiated SSO redirection to then receive it back with the SAMLResponse later.
My API uses bearer token for authentication and the controller use Authorize attribute.
Whenever I query the API using postman. It for some reason sends a ARRAffinity cookie with every request along with the bearer token.
However, when I call the same API endpoint with fiddler without he cookie. It fails with a 401 Randomly. YES Randomly some requests would get 200 success and some would fail with 401.
However, when I pass the ARRAffinity cookie via fidler. It works without any failure.
Is there a way to stop Web Api or azure from generating the ARRAffinity cookie. I just want to use bearer and not the cookie.
Is there a way to stop Web Api or azure from generating the ARRAffinity cookie.
We can easily turn ARR Affinity off in the azure portal. detail steps are as blow:
Step 1: Navigate to your Web Api in the Azure portal.
Step 2: Select Application settings in the Settings blade.
Step 3: Off ARR Affinity.
Step 4: Select Save.
For more information please refer to document
I am using ASP.NET WebAPI for a web service that I am building. He web service will use the Identity service to authenticate users.
I am a bit stuck as to how to authenticate users externally. Our current system is very basic- we send a username and password in the XML request as a separate field and it is all done in 1 request.
From what I can see from looking on Google, the best way is to request a token from the Ali and then pass this token in subsequent requests. Is there a way where I can do it all in 1 request (that is, send to the API my request for data as well as the username/password or perhaps an API key in a single request?)
From what I can see from looking on Google, the best way is to request
a token from the Ali and then pass this token in subsequent requests.
Is there a way where I can do it all in 1 request (that is, send to
the API my request for data as well as the username/password or
perhaps an API key in a single request?)
I'm not sure why your web service want to know user's username and password in Token based Authentication.
In Token based Authentication, your web service should not ask for user's username and password.
Instead, user first verifies the user name and password using a token issuer that your service trusts.
Upon successful verification, the token issuer provides the user with a token. Once the user has that token, it uses it to call your service.
For that, you do not have to reinvent the wheel. Here is JwtAuthForWebAPI nuget package for OAuth2 and OpenId Connect.
It is not secure at all to keep sending username/password with each request, you need to configure your api to issue access tokens for specified life time i.e. 24 hours. To do so you need create and end point (/token) which accepts the username/password validate the combination then issue an access token.
The client which receives this access token is responsible to store is securely and transmit it with each request to an any protected resource using the request "Authorization" header using bearer scheme.
As well you can not do this in one request, you need to obtain the access token at the beginning the you keep calling your protected resources using this access token until it is expired.
You can read more about this in my detailed blog post about Token Based Authentication in Web API
I've written my own login app to protect my api following the oauth-login-app example.
I've implemented the web server flow and everything works great.
My question is: how should I handle an authentication failure at step 3? How do I tell he client app that the authentication failed? The user could either press the cancel button, or refuse permission or just enter the wrong details.
When you initiate OAuth 2.0 (dance) with
/authorize
the user-agent land on /login page (created/hosted by you),
post redirect.
enduser(user-agent) submits the username/password
to the page hosted by you. Here you collect the credentials and
submit to Apigee, and if authentication fails, send a HTTP 401
response. Now your application should be in position to re-render
the login page and with a flash "invalid credential".
Now coming to if user is authenticated but rejects the authorization request in
consent page, you should redirect to the "redirect_uri" provided
by client, with error code.
How do I tell he client app that the authentication failed?
The login app will redirect the control back to the application redirect URI - with added error code/description in the URL as hash parameters. In case of success the URL is appended with code or token.
You can do this redirect from your login app directly but I would suggest to make the redirect call first to an Apigee Proxy and let Apigee Proxy send the redirect back to app. Both in case of success and failure. In this way you will have the benefit of using Apigee analytics that helps your understand how many OAuths failed for what reason etc.
EDIT:
You can use the same GenerateAuthorizationCode proxy you have built for the success flow. When login fails or succeeds, in either case you need to pass that information to this proxy. Generally the login app and this proxy should share this information using a common session store. You can not pass this information just using a redirect parameter because that can be changed by the client user agent. When you redirect to the GenerateAuthorizationCode redirect proxy, do so by appending a random session ID in the URL. That id can be used by the GenerateAuthorizationCode proxy to look up the login status from the session store. Then you can either send back a redirect with error or a proper oauth code based on if the login was successful. An easy implementation of the session store can be done using a distributed caching resource in the apigee gateway. Login app can put/get the session using an internal API. While the proxy can use policies to retrieve the session information.
The HttpUnit API for webclient says that "Will only send the authorization header when challenged for the specified realm." What does challenged mean in this case? How does HttpUnit recognize a challenge?
This refers to the way HTTP Authentication works:
When accessing a protected URL (for the first time, with no credentials included in the request), the server will send back a response that has a status code of 401 Unauthorized and a WWW-Authenticate header set to something like Basic realm="My Realm". This indicates that Basic authentication is needed for the given URL and the realm is named 'My Realm'. This is the challenge - the user agent is being informed by the server that the URL it tried to access requires authentication and it should send back the user credentials. The user agent will typically prompt the user for credentials and then retry the request, this time with a Authorization header set to something like Basic rXflcjMwYXxz where the second part is the Base64 encoded username and password pair.
In case of the HttpUnit method you've linked to, you'll see that it requires a realm, username and password. I imagine that when the a URL is accessed, if it gets back a 401 (the challenge) from the server, it'll compare the realm you passed it with the realm in the response; if it matches, it'll attempt to authenticate with the username and password supplied.
References:
RFC entry for 401
Headers for authentication
Basic access authentication
When the server responds with a 401 error, the HttpUnit throws an AuthorizationRequiredException. We can use getParameter("realm") of the exception to get the realm and send a request again with this realm name.