I do the below steps to get the security token from browser for Single Sign on authentication.
I am able to find the Token from http header. My question is:
a) How do I verify this token with active directory?
b) How do I find username from this token?
While googling it seems Java API has Kerberos5 login module to do what I was expecting. But almost all pages lacks simple examples.
The Web client accesses a AS Java resource with a GET request.
The AS Java sends back a 401 response code (unauthorized) with a request to initiate SPNego authentication by setting the HTTP header “WWW-Authenticate” to “Negotiate”.
The Web client recognizes that the AS Java host is a member of the Kerberos Realm and procures a Kerberos Client/Server Session Ticket for the AS Java from the KDC.
The Web client then sends the Kerberos Client/Server Session Ticket to the AS Java wrapped as a SPNego token in the HTTP authorization header.
The SPNegoLoginModule reads the token from the HTTP request and feeds the Kerberos implementation of the JDK with it.
The result is either successful client authentication or failure when the client request is rejected or another roundtrip to the KDC is necessary. In the case of failure, the Kerberos JDK implementation of the AS Java generates and sends back to the Web client an output token. The output token is wrapped as a SPNego token and sent in the HTTP authorization header.
Any help would be appreciated.
There is no response for long time. Found answer myself from various site on the internet.
Documented my experience in below link:
http://webmoli.com/2009/08/29/single-sign-on-in-java-platform/
Here's an open source library, http://spnego.sourceforge.net, that has some examples of what you want to do.
Related
I am writing an android app that connects to my server with a POST request. So far, I am using SHA-256 to hash and salt epoch time and use that as a third parameter alongside the username and password to make sure that the authentication is done from the app. However, an attacker could decompile the apk and figure out the salt that I am adding to epoch time, allowing them to make a POST request from wherever.
I am wondering if there is a way to make sure the POST request is being made from my app. Note that I cannot change the authentication method of the server from POST.
Thanks in advance.
HTTP Client authentication is an open process to allow vendors to implement different authentication schemes.
Apart from SSL (when run under HTTP protocol) having is own authentication mechanism (for servers and/or clients) the authentication task on HTTP protocol is managed by the WWW-Authenticate header in the HTTP header protocol. That field reflects if the server demands some kind of authentication and how the peer is going to be authenticated.
This allows peer protocol authentication (not only for the client, but also the server can be authenticated) but it makes HTTP method agnostic, as the authentication procedure is orthogonal to the method used to request information. You can use authentication with any (or all) the http methods (GET, POST, CONNECT, HEAD, PUT, DELETE, etc)
You need to read the RFC's docs: 7230, 7231, 7232, 7233, 7234 and 7235.
The more interesting to you is 7234 (it describes protocol authentication), and the documentation of the web server you are requesting to, and how the service has been configured, to get an idea of the authentication methods it supports or the credentials you must provide to authenticate the client.
Normally, the process is as follows:
the client makes a unauthenticated request of info for the target url.
The server denies the request, signalling authentication must be used, and proposes an authentication method and challenge.
The client redoes the request, but providing the requested credentials from the server.
The server accepts the request or denies it again.
To note is that, depending on the authentication method to use (e.g. BASIC is a simple username/password scheme, while DIGEST forces the user to produce a digest, based on used credentials and some server provided info) you can need more than one roundtrip to the server (the server can force you, while not common, to use two of these in chain to grant you access to the resources)
In the case of Java, probably a good source of documentation is the Apache HttpClient class, and it has some tutorials from Apache that show you how to make authenticated requests. A good reference is this.
As I understand, in authorization code flow we need to get authorization code and use it to get token after. We can get this code only when user confirms specified access. After that browser redirects us to redirect_uri and response will contain authorization code as parameter. So, the question: is it possible to get this authorization code without browser or any self made UI? Can we get it in application after correct request to, for example https://mysite.tuz/authorize ?
As you are using authorization code flow, the client requires a user agent (i.e browser or mobile app) to get the authorization code from the authorization server.
The whole purpose of using authorization code is that it can be passed via the user's web browser (user agent) instead of passing the access tokens directly via the web browser (user agent) which is not desired. Using authorization code,the Client then can directly retrieve an Access Token from the authorization server.
So the user agent is required to get the authorization code and act as an intermediary between client and authorization server.
If you do not require a browser then authorization code flow may not the correct choice. OAuth 2.0 supports several different grants i.e ways of retrieving an Access Token. Deciding which one is suited for your case depends mostly on your Client's type.
This might help you in deciding which flow to use
https://auth0.com/docs/api-auth/which-oauth-flow-to-use
You should use client credentials to obtain token without browser or any client. But if you need to use user credentials to get access token and id token of the user without browser or mobile app you need to implement you own client which will do the necessary logic for you and fetch the token for you. I already did it in java for the testing purpose. I don't know why you need to do it but you can implement your own client in almost any programming language . But in case you will decide to go this way you have to handle lot of things.
I expect your authorization server requires Proof-Key for Code
Exchange (PKCE) - so first of all before you start to communication
with server you have to create code verifier and code challenge
(google can help you with that :) in java it is quite simple)
Then you should start communication with server sending get request to url which ends with 'auth' you should send query params as: response_type (which is 'authorization_code' in your case), redirect_uri, client_id, code_verifier, code_challenge, scope, code_challenge_method (probably 'S256')
Then you receive I think two redirects from server so it is better to have some client in java which will automatically call those redirects. I used apache http client for my implementation. It has lot of features.
After successful redirect server will return login page to your client. It depends on authorization server but in this page you should put the data as username and password and submit the page. I have simply parsed the returned page and get the url for user authentication from it and simply make post request to that url with user credentials data sent in encoded form entity. In apache http client you will have all cookies from previous communication set (until you close the client) since apache http client automatically set all cookies returned in previous communication from server.
After make authentication request server will send you two redirects and you can store those redirects int http client context which you will provide for http client when you call authentication url.
In the last redirect there will be query parameter sent be server named "CODE" this is really important for you since you will use it to get token from the server
And finally you have to make one last post request to authorization server with url ended as token. So make a post request with GRANT_TYPE, REDIRECT_URI, CODE (you received in previous redirect), CLIENT_ID, CODE_VERIFIER (you have generated at the beginning);
Then authorization server will send you token and that's all
I have a web project that needs to pull some data from a hosted versionone instance. The versionone instance uses SAML authentication for single sign-on.
The single sign-on itself uses a username and pin+one-time password for authentication so it is nearly impossible to hard-code those values into the application.
Is there a way to handle this situation? Can I set something in the header of the request to bypass the single-signon process?
As of release 13.1, VersionOne supports OAuth2 for authentication against the API endpoints. Both the Webserver flow (where the hosted instance POSTs auth tokens to your waiting HTTP server) and the Out-of-band flow (where the hosted instance gives the user a code to copy/paste to the client) are supported.
That may be a better match for your requirements, as the SAML process is difficult to complete without a web browser and user present.
Once the OAuth2 credentials are obtained by the app, it can operate without user intervention. At any time, the user may revoke the app's permissions inside of VersionOne.
With OAuth2, the process is:
Register your app with VersionOne, thus creating a client secret
Configure the app with the client secret data from the registration
Have the app request a permission grant, which sends you to the VersionOne server.
Login to the server as the user you wish the app to act as, and accept the grant.
Copy the grant code back to the app if using the out-of-band flow.
The app contacts the VersionOne instance and exchanges the code for a persistent token.
The app can apply the token as an "Authorization: Bearer " HTTP header to achieve access to the VersionOne endpoint
If the token has expired and the request returns Unauthorized, the client may attempt to refresh the token and try again, without user intervention.
There is some documentation available on the VersionOne community site.
And a few (in-progress) examples in the VersionOne OAuth2 Examples repository
We also have a (beta) HTTP proxy that can run on your app's server, forwarding requests to the VersionOne instance after wrapping them with OAuth2 and SSL.
My question is similiar to How should I be implementing the HTTP POST Protocol Binding for SAML WebSSO Profile?, but I don't see exact answer that I needed. This is my case. I already implemented Service Provider for WEB SSO SP-initiated POST redirecting and my IDP is active directory and STS is ADFS2.0. After user log on, I need to send another AuthnRequest to ADFS2.0 without user agent interaction. Is it possible with HTTP POST? Or to send over HTTP POST, user agent interaction must needed. I set isPassive=true. I try to implement using Java.
Ok you could build an authentication request and send it to ADFS2 using any HTTP client (i.e. http://www.innovation.ch/java/HTTPClient/ works for me). But ADFS2 will always reponse you with the Login Form. The problem is that in the request you were missing the cookies that ADFS2 is using for tracking your session (SamlSession cookie).
Hope it helps,
Luis
ps: why do you need to send another authn request?
We have a REST API delivered via Apache Tomcat that a Flash web application is intended to communicate with.
Authentication is performed with Basic auth over SSL (although the password inside the basic auth is SHA-2'ed). The issue is that using basic authentication for the Flash client is causing the standard browser log-in box to appear because of "WWW-Authentication: Basic" in the header. Flash is unable to bypass this by manually setting the Authorization header prior to the request.
Other clients need to be able to authenticate via the existing mechanisms, so rewriting the authentication logic would not be ideal.
I have the idea that the authorization headers sent to and received from flash client could be dynamically rewritten to use another name for Basic auth which would cause the browser not to understand the auth mechanism and not present the dialog box. Authentication headers to and from Tomcat could be rewritten from "WWW-Authenticate: Basic" to "WWW-Authenticate: PretendBasic" but ideally the built in container security could still handle the basic auth after the rewrite.
I wrote a filter to rewrite inbound headers as "WWW-Authenticate: PretendBasic" as "WWW-Authenticate: Basic" hoping the next filter chain would be auth and the request would be handled as normal. Unfortunately the Servlet specification states that a filter cannot be inserted prior to authentication. I think the only possibility of this working is to create a stackable JAAS authentication module that would first perform a header rewrite on requests if coming from the Flash client, and then pass authentication through to the existing container managed security systems.
Since I'm unfamiliar with JAAS, I'm hoping the community could shed some light on how to accomplish this, and whether it is a good idea in the first place.
If your flash application always works with server protected with basic, it can ask for the credentials prior to generating the first request to the web services. So the first request will already include the authentication header and you won't receive 401 in response.
I would have thought that enabling authentication via WWW-Authenticate, as an imitation of HTTP Basic, would do the trick.
Where you currently have HTTP Basic authentication working, just add another authenticator which does HTTP Basic but against the WWW-Authenticate header instead of the Authorization header.
You can then include the header in Flash and ignore HTTP Basic in that client.
I've done similar, using 3 different authentication schemes, on Jetty. I'm not sure what the Tomcat way would be.