Home / 0.2
Name Modified Size InfoDownloads / Week
Parent folder
README.TXT 2012-08-27 5.4 kB
sp.war 2012-08-27 14.7 MB
idp.war 2012-08-27 15.1 MB
Totals: 3 Items   29.8 MB 0
This project contains two sample Java web applications: an Identity Provider
(IDP) and a Service Provider (SP).  The goal of this project is to show how Open
SAML can be integrated with Spring Security to provide a cross domain security
solution.  This does not use the Spring Security SAML extension project.  This
project is only a recipe, it was not meant provide a framework with re-usable
components. 

SAML is only a specification. It does mandate the answers to many questions that
will come up in any in any cross domain security solution.  How is trust
established between the Service Provider and Identity Provider?  What binding is
used to send SAML messages between the IDP and SP?  How will a Subject be
identified to a Service Provider?  What level of information does an Identity
Provider give to a Service about a Subject?  Does this include role/access
rights?  And many more that I can't think of off the top of my head... 

This solution is not meant to replace the functionality that is offered with a
fully featured Identity Provider (e.g Shibboleth, PingIdentiy).  It does not
offer the flexibility that these other solutions provide, but it does offer a
simple, SAML compliant solution that might be useful in some situations.
 


#############################################
#                                           # 
# Authentication Flow                       #
#                                           # 
#############################################

Requests to protected resources in the SP will result in a Signed AuthnRequest
to be sent to the IDP.

The IDP will use form based login to challenge users that have not yet
authenticated beyond a level of ROLE_ANONYMOUS.

Failed login attempts at the IDP will result with a signed AuthnResponse being
returned to the SP with a status code of
urn:oasis:names:tc:SAML:2.0:status:Responder 

Successful login attempts OR  users that still have a valid session at the IDP
will result with a signed AuthnResponse being returned to the SP with a status
code of urn:oasis:names:tc:SAML:2.0:status:Success.

The SP will convert successful AuthnResponses into a SAMLAuthenticationToken.
The principal and GrantedAuthorities are conveyed in the Assertion. 

Unsuccessful AuthnResponses will be logged and will return the user to the IDP
for a chance to successfully authenticate. 


#############################################
#                                           # 
#   Additional Features/Details             #
#                                           # 
#############################################


All SAML Requests/Response are made using the HTPPPostBack Binding.

Private/Public keys are stored in a JKS keystore whose contents have been Base
64 encoded for easy access by the credential manager.  The keystores are
included with the source to allow for modification/inspection.  All passwords
are 'secret'.

The digital signatures of the Request and Response are verified against the
senders public key.

In addition to the signature check, there are two additional Open SAML Security
Policy Checks: IssueInstant and MessageReplay.  IssueInstant insures that a
message is only valid for a narrow window of time.  MessageReplay prevents the
same Message from being processed multiple times.

The IDP allows for direct access through form based login.  That is, it supports
users accessing it directly as an application as well as providing SSO services
for an SP. 

There are several interesting integration tests that are included with the
projects. They produce/consume SAML messages and output to the log.


#############################################
#                                           # 
# Deploying the pre-built WARs.             #
#                                           # 
#############################################

You should be able to deploy both applications by updating the
application.properties file contained in each WAR.  At a minimum, the
WEB_APPLICATION_HOST_AND_PORT will need to modified in both applications, as
well as the IDP_URL in the sp.war.

Xerces and Xalan need to be in the endorsed directory of your application
server.  Open SAML will NOT work if you use a different XML Parser.  

These applications have been tested in Tomcat 6 and 7, but should work in 
other containers as well.


#############################################
#                                           # 
# Building the sample applications.         #
#                                           # 
#############################################

All three projects are built using Apache Ivy and Apache Ant.

The spring-saml-common project must be built first as it contains common code 
that is used by both the IDP and SP.  There is also an ivysettings file that is
included that can be used to resolve dependencies in the shib repo.  

#############################################
#                                           # 
# Changelog                                 #
#                                           # 
#############################################

Version .2

	- Updated to Spring 3.1.2 and Spring Security 3.1.1
	- Updated to Open SAML 2.5.3
	- Fixed the URL to the Shib repo in ivysettings.xml
	- Added Selenium Tests to verify base functionality. Both IDP and SP 
		must be deployed for the selenium tests to work. 



 
Source: README.TXT, updated 2012-08-27