Archer Security Provider
Archer Security Provider is a server component which provides X509 short-term/proxy certificates based on Shibboleth credentials.
The module is built as a Web application which is protected by shibboleth. Archer Security Provider uses SLCS server for the certificate generation. For more information of SLCS, please visit SLCS Homepage.
In the current version of Archer Security Provider, a CA is bundled together for testing purpose. For production, it is recommended to replace this CA with Microsoft CA software or Redhat Certificate Management Server.
|Installation and Configuration|
The latest source code for this module can be downloaded from Archer svn repository here .
The following steps are necessary:
The binary of version 0.2 can be downloaded here
To test the application, go to /ArcherCertProvider/Certs
This web site will generate a certificate based on the shibboleth attributes
of a authenticated user.
A test site has been set up on http://mersey.its.monash.edu.au/ArcherCertProvider/Certs, currently with Open IDP level 2.
- (Optional) Set an evironment variable name ARCHER_HOME pointing to a directory where the configuration of the Archer Security Provider will be. If this is not set, the default value of this variable will be $HOME/.archer. In other words, you need to create an .archer folder under your home directory if ARCHER_HOME is not set.
- Download a sample configuration and extract the file to ARCHER_HOME ($HOME/.archer by default). You will see the following folders under ARCHER_HOME:
ca folder: where a sample ca certificate and a corresponding encrypted private key are present.
config folder: where the main configuration files - slcs.xml, archer.xml, and log4j.xml - reside.
jks folder: where a sample java truststore and keystore can be found. These by default have an entry of Archer mersey server.
log folder: where the log file supposed to be.
- In the ARCHER_HOME/config/archer.xml file:
a. Modify the according to the shibboleth attribute/CGI header mappings.
Currently email is used as the unique ID, it can be replaced by any unique id defined by the IDP.
b. Point to the correct location of an existing myproxy server. If this section is commented out, the system will bypass myproxy storing step.
The myproxy server should be configured to trust the certificate in section. If the auto detected dns name of the myproxy is different to its name then the destination subject name needs to be set in .
c. The section is often unchanged except the port. Generally, it is /ArcherCertProvider/SLCSServer.
d. The and are the CA certificate and key used to sign certificate request.
slcs.xml: Modify the section to use correct keystore and truststore.
Configure your server to have jsp/ArcherCertProvider.jsp protected by Shibboleth.
Configure log4j for your servlet engine. With Tomcat 5.*, log4j jar file needs to
be in $CATALINA_HOME/common/lib directory. Make sure your log4j config file
in archer.xml points to a correct one.
Add the certificate of the OpenIDP level 1 (and 2) servers (both on port 443 and 8443) as trusted certificates to your JVM.
The picture above depicts different components inside the ArcherSecurityProvider software (the top circle) and as well as interactions between them. It also illustrates the interaction between the ArcherSecurityProvider and the client components, i.e Archer Desktop Client.
The ArcherSecurityProvider consists of:
ArcherCertProvider : The front end component where all the certificate requests should destine to. This component is a Shibolleth protected servlet. It exposes Web interfaces as well as SOAP interfaces for certificate retrivals.
SLCS Server : A cutdown version of the original Swiss SLCS. In particular, the group management and session caching functionalities in SLCS has been stripped off. It means that the new modified SLCS is much more lightweight and no backend database is required. The modification to SLCS is minimal and the modified source code can be found here.
Archer CA: A CA server which can sign certificate requests. The CA supports the Simple Enrollment requests/responses of PKIX-CMC protocol (RFC 2797). It is still in an early development stage.
MyProxy Server : A myproxy server which is configured to accept to store any credentials generated by the Archer CA.
The interaction between a client (i.e. ArcherDesktopClient) and the ArcherSecurityProvider often happens as follows:
In step 1, a client sends a request for a shorterm certificate to an interface exposed by the ArcherCertProvider.
In step 2, The ArcherCertProvider, being protected by Shibboleth, redirects the client through a WAYF or lands the client directly to the client's home IDP where the client can authenticate.
Backend channel communication between the IDP and the ArcherCertProvider happens in step 3. User attributes are released to the ArcherCertProvider.
In step 4.1, the ArcherCertProvider checks whether with these user attributes, any corresponding credential can be found in the myproxy server. If such a credential can be found, the ArcherCertProvider returns it the client and the interaction sequence ends.
Alternatively if such a credential in step 4.1 cannot be found, the ArcherCertProvider forwards a certificate request to the SLCS server in step 4.2.1. The user attributes are tagged in this request.
Next in step 4.2.3, the SLCS server carries out its normal routine of generating a short term certificate by communicating with the Archer CA using CMC protocol.
A short term certificate is returned and forwarded in steps 4.2.2 and 4.2.3, it is then stored in MyProxy.
Finally a certificate is retrived from the MyProxy by the ArcherCertProvider and returned to the client in step 5.
The application provides an normal servlet and a WS endpoint that return a proxy certificate. A client must
be authenticated with Shibboleth before making any request for certificates.
jsp/ArcherCertProvider.jsp: This Wepp app accepts a shibboleth authenticated request with a callback parameter
which points to a certificate consumer.
services/ShibCertProviderWS: This WS accept a desktop shibboleth authenticated request (evidenced by a shib handle)
and returns a certificate.
The ArcherCertProvider has been installed for the demonstration purpose on mersey.its.monash.edu.au.
To get a certificate through its Web interface, you can go to https://mersey.its.monash.edu.au/ArcherCertProvider/Certs
To use the postback interface, you can set the value of the "callback" paramter as the url endpoint that you want to post the credential to. This parameter is then sent to http://mersey.its.monash.edu.au/ArcherCertProvider/jsp/ArcherCertProvider.jsp
using HTTP POST or GET. At the url endpoint, you can retrieve the credential through a parameter named "credential". The credential value is encoded in Base64 so you need to decode it to get back an array of byte. See the PostBackTest.jsp source in the jsp folder for detailed information.
For example with HTTP GET:
where PostBackTest.jsp is a simple test url which prints out the content of the credential posted back from ArcherCertProvider.jsp.
Important: In this demo server, ArcherCerProvider is configured to use the first field in the eppn as the certificate CN. It does not use the SharedAuEduPersonToken since this token length and special characters can cause problem to SRB servers. GridFTPServer does not seem to suffer from this problem.
Another ArcherCertProvider has been installed and running at slcs.federation.org.au, e.g. https://slcs.federation.org.au/slcs/Certs for the Web interface.