NTLM authentication with Java outside Domain - java

My question is simple, the answer might be complicated though.
Can NTLM authentication be done outside a network from a tomcat server using Java code to do the authentication? If so, what sort of certificate/trust exchange is required? What other requirements are there? Would it depend on the setup of the server needing to be authenticated against?
I can't find this exact question anywhere and am hoping for some general info on this, not a specific implementation, although that would be cool to see.

Not aware of NTLM, but common approach is to use LDAP AD.
Spring security has a good support on LDAP authentication: http://docs.spring.io/spring-security/site/docs/3.0.x/reference/ldap.html
You need to be familiar with your organization's AD structure. Below is sample configuration from JIRA LDAP AD setting which roughly highlight configuration item required to setup LDAP authentication

I found that the answer to this is to use something like SAML or OAuth to authenticate outside the network/domain. Working on implementing SAML.

Related

How can I use something like Auth0 when my front-end and back-end are separate?

I have been working on an app where the front-end (React) and back-end (Micronaut) are separate. They currently communicate via REST use Micronaut's built-in JWT authentication. I'd like to use something like Auth0 or Keycloak to avoid having to implement user management code.
Is that possible given the separation of my front-end and back-end? If so, are there any resources I can use? I haven't found many concrete answers to that question, but have been looking into OAuth's Client Credentials Flow. Is that what I want in this case?
Auth0 has documentation on how to do authentication through their authentication code flow which can work well for REST APIs. It uses jwts, but gives you an easy way to verify the jwts and get the token info using their get user info api.
If this is not what you’re looking for, I would recommend checking out the Auth0 authentication API docs. It walks you through setting up many different kinds of complex authentication flows and (in my opinion) makes them pretty easy to implement. Hope that helps!

Building a Java OAuth2.0 authorization server with Keycloak

TL;DR
Objective: Java authorization server:
OAuth2.0 authorization code grant flow with fine-grained permissions (not a mere SSO server)
User management and authentication: custom database
Client management and authentication: Keycloak
Questions: What are the best practices for implementing a Java authorization server with applicative permissions handling backed on Keycloak?
What Keycloak adapter/API should I use in my development?
How should the users be managed/appear in Keycloak if they are to appear at all?
Forewarning
I am quite the beginner with Keycloak and, though I think I understand the main principles, it seems to be a rich tool and I fear I may still be mistaken about some aspects of the best ways to use it. Please do not hesitate to correct me.
Context
We are looking at implementing an API requiring our users (henceforth "users") to grant permissions to third party applications (henceforth "clients").
Our users are stored in a custom existing database-based user management system. As for our clients, we are thinking of using Keycloak.
The users consent will be given using an OAuth2.0 Authorization code grant flow. They will log in, specify which permissions they grant and which they deny, and the client then retrieves the access token it will use to access the API.
It is my understanding that Keycloak can handle the authorization token but it should not know anything applicative, which our permissions are. As a consequence, I thought of building a custom authorization server which will use Keycloak for all identity/authentication problems but will handle the applicative permissions by itself.
Then, we will use Keycloak for client authentication and authorization code/access token management, and an applicative part will check the permissions.
Problem
Besides my first experimenting, I've been roaming the Internet for a week now and I'm surprised as I thought this would be quite a standard case. Yet I found next-to-nothing, so maybe I'm not searching correctly.
I've found many Spring/Spring Boot tutorials1 on how to make a "simple authorization server". Those are mainly SSO servers though, and few do manage permissions, with the exception of those mentioned in this SO answer2. That I think we can deal with.
The real problem I have, and that none of the tutorials I have found are treating, is the following:
How do I integrate Keycloak in this authorization server?
I've been having a look at the available Java Adapters. They look OK when it comes to authenticate but I did not see hints about how to manage clients from a custom authorization server (ie administer the realm).
I therefore suppose I should use the admin API. Am I correct and is it good practice? I saw no adapter for that, so I suppose I should then use the REST API.
I also wonder how we should integrate our users in design? Should they be duplicated inside Keycloak? In this case, should we use Keycloak's admin API to push the data from the authorization server or is there a better way?
Finally, am I missing some other obvious point?
Sorry for the long message and the many questions, but it all boils down to one question in the end:
What are the best practices when building an authorization server using Keycloak as a backbone?
1. Some examples:
Spring Boot OAuth2 tutorial -
A blog post -
Another blog post
2. I've mainly focused on the sample app provided by Spring Security OAuth
Building Java OAuth2.0 authorization server with Keycloak
This is possible but is bit tricky and there is lot of thing which needs to be customised.
You can derive some motivation from below repo.
keycloak-delegate-authn-consent
Building custom Java OAuth2.0 authorization server with MITREid
If you are open to use other implementations of Oauth and OIDC,I can suggest you MITREid which is referrence implementation of OIDC and could be customized to a great deal.Below is the link to its repo and its open source.
I myself used this to requirement similar to yours and it is highly customizable and easy to implement.
https://github.com/mitreid-connect/OpenID-Connect-Java-Spring-Server
MITREid Connect uses Spring Security for its authentication, so you can put whatever component you like into that space. There are lots of good resources on the web about how to write and configure Spring Security filters for custom authentication mechanisms.
You'll want to look at the user-context.xml file for where the user authentication is defined. In the core project this is a simple username/password field against a local database. In others like the LDAP overlay project, this connects to an LDAP server. In some systems, like MIT's "oidc.mit.edu" server, there are actually a handful of different authentication mechanisms that can be used in parallel: LDAP, kerberos, and certificates in that case.
Note that in all cases, you'll still need to have access to a UserInfo data store somewhere. This can be sourced from the database, from LDAP, or from something else, but it needs to be available for each logged in user.
The MITREid Connect server can function as an OpenID Connect Identity Provider (IdP) and an OAuth 2.0 Authorization Server (AS) simultaneously. The server is a Spring application and its configuration files are found in openid-connect-server-webapp/src/main/webapp/WEB-INF/ and end in .xml. The configuration has been split into multiple .xml files to facilitate overrides and custom configuration.

How to authenticate users from a rest service

I am trying to authenticate users with a REST service I built using drop wizard. From previous questions I found great example of authenticating with openID on github: https://github.com/gary-rowe/DropwizardOpenID
However, I don't want to deal with openID at the moment and simply want users to 1. Signup, 2. Signin
My questions/confusions are:
For Signup: I'm thinking about sending users's username/password as a POST request with the credentials as either form parameters or part of JSON body. However, isn't there a security risk here of sending password in plain text?
For Sing-in I'm thinking about using Authenticator in Dropwizard.
I don't want to store passwords in plain text. What strategy should I follow after I get the users' password in the POST as plain text? I'm looking for some java libraries that can assist in password salt and MD5
Thanks for the shout out for the Dropwizard OpenID project. Glad it was able to get you started.
If you want a pure web form type approach, take a look at another of my projects MultiBit Merchant which provides multiple authentication methods (web form, HMAC, cookie).
You'll need to dig around to really see it working since this project is not designed as a demo as such and is very much a work in progress.
After loading the project, look for WebFormClientAuthenticator which will get you in the right area.
The general principles involved with Dropwizard authentication are discussed in this blog article. Although it targets HMAC you can easily adapt it for web form or cookie using the source code referenced earlier.
It's all MIT license so just use it as you need.
Looking at the docs, we can see that Dropwizard supports a standalone OAuth2 implementation:
http://dropwizard.codahale.com/manual/auth/#oauth2
OAuth2 has several advantages, many of which can be read about here: OAuth 2.0: Benefits and use cases — why?
Things to note:
when dealing with authentication, you should always host over HTTPS to ensure transport encryption
Dropwizard claims their OAuth2 implementation isn't yet finalized, and may change in the future. As a fall back, they do support Basic auth as well, which when used over HTTPS would be still reasonably secure.
Implementing this does not involve using any third party "social" authentication services such as Google or Facebook.

WebServices security with SAML (SSO) - How to?

The Problem:
I want to implement a set of Webservices, protected with SAML. I need to authenticate the users, and also need to authorize based on the user role.
I found some questions similar to this one, but none with satisfactory answers.
The scenario:
Java Webapp accessed only using Webservices;
SOAP - metro;
Clients use some Desktop application that they will develop.
Key features that I need:
Free software;
SAML 2.0;
LDAP(or similar solution) to manage users information;
Message level security (SOAP).
The question:
I study some SAML (SSO) solutions (e.g. Shibboleth, opemAM, JOSSO...);
Can I use any of those, without compromise any of the key features?
Or do I need to implement my own way to handle the SAML tokens?
How to do it?
Thank you!
Here are some results that I found, and/or some tips from the answers:
Shibboleth:
http://shibboleth.1660669.n2.nabble.com/Web-Service-End-to-End-Security-td5526934.html
Shiboleth doesn't do ent-to-end, just point-to-point.
http://www.predic8.com/shibboleth-web-services-sso-en.htm
Requires a proxy module for authentication, before the SP.
OpenAM:
https://wikis.forgerock.org/confluence/display/openam/Web+Services
Doesn't present a service provider (SP). Define an architecture based on client-server, where client explicitly ask for tokens, when use web methods to authenticate.
WSO2:
http://wso2.org/library/articles/2010/07/saml2-web-browser-based-sso-wso2-identity-server
Doesn't provide SP, you need to implement it using OpenSAML.
Still searching, please contribute!!
I am an architect at WSO2. WSO2 produces WSO2 Identity Server supporting all the features you required. You can deploy WSO2 Identity Server over an existing LDAP user store and make it act as an SAML2 IdP. We are using this functionality of Identity Server in our Platform as a Service [PASS] offering - https://stratoslive.wso2.com for SAML2 single sign on.
This is a good starting point and you can download WSO2 Identity Server from here.
Since no one answered with a valid option. I decide to secure the services with metro SAML, and try to provide the tokens using OpenAM.
For this you could have a look at jasig CAS.
We don't use SAML yet, but it should work as described here

Username in HTTP Header for SSO

I am looking to add single sign on (SSO) to one of my web applications. I don't want anything heavy at the moment, I just want to know the userId of the logged in user, without the need for them to enter a username.
The web app is an internal application, so I can guarantee they are coming from a Windows PC etc.
I have looked at jCIFS, but this doesn't seem to be supported any more, and recommends a commercial product.
I have also looked at WAFFLE, but I am building SSO for a playframework application, which does not use a Servlet stack, so I can't make use of the SecurityFilter. I have tried to make sense of the WindowsLoginModule, but couldn't really understand what I had to do to implement it.
Is it possible to just get the username from the HTTP header, or does it require some negotiation first before it will post the header?
You want the windows user to automagically login to your intranet webapp. So the user accounts would sit in an active directory and the usual microsoft way would be to use a protocol like NTML oder Kerberos. Applications are generally advised not to use NTLM, although there are enterprises still using NTML (and jCIFS) for SSO.
A quick search on Kerberos and Java showed this article. It seems to depend on the Java EE stack (JAAS).
For a more stripped down approach: Usually, you cannot sent the username in a http request in a portable way. With ActivX you could do:
var wshshell=new ActiveXObject("wscript.shell");
var username=wshshell.ExpandEnvironmentStrings("%username%");
On the server side, you can parse the http header and extract the username with your technology of choice.
Well, security doesn't matter in your playframework application?
Why don't you use long-living cookies?
Hope it helps!
In an intranet context with ActiveDirectory and workstations registered in the domain, the HTTP SPNEGO Negotiation support is the best option. But it requires specific skills around ActiveDirectory and Java Kerberos implementation.
Spring Security provides implementation and documentation to set it up. But Secure.Security is not designed to support token-based authentication like HTTP Negotiation. So using Spring Security will require a specific integration module.
Other options are OpenID and shibboleth but both requires a dedicated server, which can be configured to do SPNEGO itself. Thanks to available Play modules, integration in your application will be easier.
The only way to get the username in an HTTP header without client-side complex and unsecure/unreliable tweaks is to use an authentication proxy between browsers and your application server. Most of these proxies also support Kerberos SPNEGO as authentication mean.
Non-heavy answer
It sounds like it should be possible to get your ops team to implement a Group Policy which will send the logged-in username down the wire as an HTTP Header.
Otherwise, you're correct in your assumption that there is some sort of negotiation "dance" between IE and your server. See here. Perhaps you can fake this dance in your Play code.
Heavy answer
I know jCIFS and this example uses servlets and filters, but the important bits of code can be extracted and a custom Play Authenticator can be built (I can paste a Scala example override of play.api.mvc.Security.Authenticated , but your answer is tagged Java). You only need the request headers (not body) so it should be doable in an authenticator.
PS jCIFS seems to have had an update since your post, so I'm presuming you'd reconsider using hacking it. I'm wary of unmaintained libraries too, but sometimes they just reach a maturity and stability which alleviates the need for any more updates.
Active Directory uses Kerberos, so all logged in users should have a kerberos ticket.
A fast google found this:
https://blogs.oracle.com/wyllys/entry/kerberos_web_authentiation_with_apache
If you want the windows logon details, I think it's your only option.
You can try to use Shiro for enabling SSO in your application.
Shiro id independent of the servlets and since your framework does not support Servlets you can very easily go for Shiro.
You can create a Realm where you define the hashPassword.
You can configure the username and the hashPassword and ask the shiro to authenticate your user with the hashPassword.
You will then assign role for the user which will serve your purpose of SSO.
You can authenticate user for more than one application and hence when user logs into another application the shiro has already authenticated you and hence it will straight away log you inside the application..
You can go through the shiro documentation(exhaustive and you should be able to configure it on first go) from the following link:-
http://shiro.apache.org/
It provides you many out of the box functionality for authenticating and authorization along with security and Cryptography modules.
The username isn't sent in the header. Even if it was this shouldn't be relied upon as a savvy user could fake the values.
If NTLM would be a valid option for you Jespa might be a good alternative to JCIFS. Jespa (unlike JCIFS) supports NTLM v2, among other things. The limited version of it (up to 25 users) is free.
You can always get any header from filter. See javadoc for HttpServletRequest.

Categories