Implementing java SSO via ADFS - java

I am implementing Single Sign On in java application via ADFS.
I have only ADFS URL, and its metadata.xml.ADFS is using SAML. Access to the ADFS logs I dont have. I need to implement SSO, so I can only send requests from https? How can I achieve https on tomcat If, maybe via Azure? Maybe I can Set up this environment on Ubuntu? I used very many example and non of them are working, usually, I get response from ADFS server saying "An error ocured, contact your administrator". Is there any tutorial that is working?

Found this useful posting on SO on how to ADFS SSO-enable a Java app. Hope this helps.
Your application needs to act as a SAML SP, either directly (from your code), or indirectly (e.g. through SAML SP support on reverse proxy, application server, ...).
For direct options (which require more modifications to your application) you can:
• code the SAML SP yourself (most likely with OpenSAML, you can find examples in sources of existing products)
• use a ready-made product to integrate into your application, such as Spring SAML or OpenAM Fedlet
For indirect options (which require less modifications to your application) you can:
• use Shibboleth SAML SP plugins on your Apache reverse proxy (if you use one)
• deploy SAML SP as another application on your container (e.g. Spring SAML or OpenAM) and make it communicate with your application - so SAML SP performs authentication with ADFS and communicates this to your application e.g. through a shared cookie, or a custom token
You can find more comparison details and considerations in this thread.
ADFS 3 should have support for OAuth Authorization Server and it might well be an easier way to integrate, see here and here. Implementing authentication using OAuth is generally significantly easier than SAML, with no relevant disadvantages.

Related

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.

Java Sample code for Authentication with Ping Federate and SalesForce

I'm new to SAML, SalesForce and PingFederate and have a need for integrating a Java based server with SalesForce and PingFederate using SAML assertions. Essentially what I need is to be able to do is to allow a SalesForce authenticated user to use the Java based server without having to re-enter user/pass info when the directed to the Java server from SalesForce. In turn, changes made from the Java server will need to be pushed back to SalesForce as well.
I've been trying to find Java code to handle authentication that I can incorporate with the Java based server, but I find bits and pieces here and there, but not a complete solution.
Are there any good Java sample code for authenticating against SalesForce with PingFederate using SAML?
TIA
There are a couple things you need to clarify first, the solution would follow.
Who's going to be the Identity Provider, Salesforce or PingFederate?
Is the Java Application going to be a standalone SAML 2.0 Service Provider or directly integrated with PingFederate, which takes care of federation?
Salesforce as IdP
Either configure a SAML 2.0 Connection between the Salesforce IdP and PingFederate as the SP. (Salesforce doc, PingFederate doc)
Or use the Salesforce Cloud Identity Connector for PingFederate, which provides an IdP adapter. (doc)
Salesforce as SP:
Either configure a SAML 2.0 Connection between PingFederate as the IdP and Salesforce as the SP. (PingFederate doc, Salesforce doc)
Or use the Salesforce Connector for PingFederate, which simplifies the configuration. (doc)
Java App as standalone SP:
Use one of the many SAML 2.0 Libraries for Java, then configure for PingFederate as the IdP.
Java App integrated to PingFederate:
Also called the "last-mile integration", PingFederate has several Integration Kits available which can be used for this purpose, the Java IK and the Agentless (or RefID) IK being the two coming to mind. Both of these include Sample Applications which can be leveraged. (Java IK doc, Agentless IK doc)
For your use case, there are three subsystems, mainly (1) PingFederate as the Identity Provider (IdP), (2) Salesforce as an application, and (3) your Java based server application. Single sign-on (SSO) occurs via PingFederate issuing SAML tokens to each application. Once a authenticated session occurs by accessing one of the two applications, the second will not be challanged to re-authenticate granted SSO p[olicy has not expired.
There are two SAML connections here, mainly the Salesforce connection and the connection to your Java Application. There are many tutorials on the internet to configure the Salesforce-PingFederate SAML connection. Your question asking "how to setup a connection to your Java based application from PingFederate". There are a couple of options here using PingFederate. I recommend you download the Agentless (also known as reference ID) integration kit and the Java Integration Kit. Both of these integration kits allow "last mile" integration to your Java based server application. Both of the kits have documentation and samples. My preference is the Agentless integration kit since it uses REST API and does not require any libraries being compiled into your application.

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

Using ADFS and SAML for querying AD with Java

I need to query AD outside organizational boundaries from a Java application and get a list of users from that with proper authentication and privileges using ADFS and SAML.
I am new to ADFS and SAML and claim based authentication. I need to use these technologies with JAVA.
How can I integrate ADFS with java in this scenario?
ADFS doesn't offer a means to get "a list of users". For that you should look at traditional ways of querying AD using LDAP (as proposed by Aaron).
As you point out - ADFS provides claims-based authentication features, via protocols such as SAML 2 and WS-Federation. These protocols are typically used to get a security token for a user, and use that token to authenticate them at a Service Provider (external application). This interaction would be done on a user initiated basis, with them first authenticating to ADFS (acting as the Identity Provider).
It's not clear to me what your entire project entails, but perhaps that approach could be applied? If not - you may have to look at opening up firewall ports to access AD via LDAP (or LDAPS).
Here is a good place to start: http://jeftek.com/222/using-java-code-with-active-directory/

How to write a java web service to do remote login?

I have two application. I need to do a single signon from application a to application b.
I thinking of using web service. I wonder how do i go about that approach.
Can anyone advise?
Assuming these are web applications - you must implement some type of shared trust model between the applications.
Under no circumstance should you write your own. That is too easy to screw up and there are plenty of existing (both open and commercial) to choose from.
Here are following options:
1 - If everyone is running Windows - you could just Windows Native Authentication (aka SPNEGO)
2 - You could implement some type of SSO system. Popular systems are CAS, Oracle Access Manager, CA SiteMinder, Sun SSO and IBM Tivoli Access Manager. While CAS is open-source, the others will also allow you to implement authorization as well, while CAS only does authentication.
Finally - make sure whatever option you choose - that it integrates with your language's native authentication & authorization framework. In Java this would be JAAS. In .NET it would be the .NET security framework. For PHP/Perl - you can leverage Apache modules. The benefit is that you don't have to become a security expert and it will make it easier to use external systems for authentication & authorization without having to re-code your app.
You could use a public key authentication scheme.
Create a keypair with a public and private key (using Java's keytool, GNU GPG or a similiar tool). Use the private key to sign a piece of information (for example a username) on application A and create a link to application B that is accessible from application A and contains the signed data. Application B can then log the user on after verifying with the public key that the request indeed came from application A (which it must have if it is able to decrypt the string).
You could of course create a opposite keypair for navigating the other way as well, or you could just use the public key and keep it secret (effectively making it a shared-secret system).
If the user tries to access application B directly you could also redirect him to application A with a parameter that says he came from application B (or do a referrer check). If he is already logged on to application A create the link with the signed data and redirect to it, otherwise present him with a logon screen and redirect after logon.
Hope that helps!
You could use an existing open source product, CAS and just implement it instead of develop your own. That way you'll be able to integrate with other applications that support the same protocol. Even if you decide to implement your own instead of using their code, there are a lot of ideas presented at the web site that would be useful for you to consider.
If the applications are hosted in the same server, then you could configure it to use single sign on. For example, in Tomcat this is achieved with a Valve.
If the applications are in different environments, then a secured Web Service is a good idea. You could for example create a public - private key pair and have application b (server) authenticating application a (client) on the client certificate. This means that application a will sign all requests to application b with the client certificate. More details about the architecture are needed for a full solution.
Are you using an application server? What is the environment for your applications?
There is a standard for propagating identity using web services called Web Service Security UsernameToken Profile. Here's a quick overview. You can send username/password or various tokens such as X.509 certificate or a SAML assertion. Some application servers web services stacks will handle WSS UsernameToken Profile, JBoss, Websphere, and WebLogic. Otherwise the web service code has to handle it. This approach may be too cumbersome depending on your environment.
There is a standard for single sign-on, called SAML. Again, this may be too heavy weight for your use-case.
In Oracle land I know there is the concept of a trusted application. Basically if you have control of both applications you can set it up like so:
Application A sends Application B, 1) Application A's username and password and 2) the current user's username. Since B knows and trusts Application A it doesn't need to verify the user's credentials, since it knows application A has already done that for it.
I assume that if you have a custom application B you might be able to do something like this. If your SSO implementation supports this then you probably don't have to do a whole lot except design your web services.
Good Luck

Categories