axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brian Reinhold" <>
Subject RE: Configure Custom Rampart STS
Date Thu, 01 Nov 2012 14:06:38 GMT
There is clearly a critical piece of information missing from the

I followed the instructions and changed the name of the issuer class back to
<issuer class="org.apache.rahas.impl.SAML2TokenIssuer"> which is the
default. I set the <operation name="IssueToken" or <operation
name="RequestSecurityToken" and it made no difference. As long as the issuer
class was set to the default rahas implementation above, it worked and the
token was issued. Change it to my class, and it fails.


So what is the piece of information missing that allows the dispatcher to
find MY class?


I would so love to get rid of this sequence spewed out by Axis2 and finally
get to work on my STS service:


2012-11-01 09:43:37,098 [http-bio-8443-exec-6] WARN  -














The other alternative is to modify the Rahas source code. You NEED the
dispatcher to call the IssueToken method because that is the only way you
can get the RahasData object. It is possible that this is the only solution.




From: Brian Reinhold [] 
Sent: Thursday, November 01, 2012 8:22 AM
Subject: RE: Configure Custom Rampart STS


Okay, that was an easy fix. But all the other questions remain a mystery. So
I performed the following experiments:


1.       Started with default service. Rahas.mar and rampart.mar in modules;
the default service.xml for the STS service is used. Result: It worked. I
got the default SAML20 token

2.       Now I modify the rahas.mar module.xml so that <issuer
class="org.apache.rahas.impl.SAML2TokenIssuer"> becomes <issuer
class="com.lni.sts.receiver.LNISAML2TokenIssuer">. Result: Failure. Unable
to load the class error. (Note that the class LNISAML2ToeknIssuer is a copy
of org.apache.rahas.impl.SAML2TokenIssuer with the package changed. Required
adding public methods to the SAMLTokenIssuerConfig class)

3.       Now I follow instructions except I do NOT remove the rampart.mar
file but just the rahas.mar file. I believe that is an error in the
instructions. I add the ‘operations’ element to my service.xml. Result:
Failure. Unable to load the class error.

I do not know how to better follow the instructions. Why can’t it find the
class. It IS present in the aar file in the services directory!






PS: When I figure out how to actually do this I will write some
documentation so others won’t have the same struggles!


From: Martin Gainty [] 
Sent: Wednesday, October 31, 2012 1:28 PM
Subject: RE: Configure Custom Rampart STS


usually that happens when you the version of Tomcat java classes != webapp
java classes

go to http://localhost:8080/manager/status
write down the version number of java you are using

recompile all of the Java classes for your webapp with the same (JDK) java
version from the Tomcat Manager Status


Subject: RE: Configure Custom Rampart STS
Date: Wed, 31 Oct 2012 13:10:58 -0400



I believe that I have followed the very limited instructions on how to
implement a custom STS service given at 

1.       First I took the code for the current default SAML20TokenIssuer
class and renamed the class and added it to my service. It’s a start!

a.        I had to add some getters to the SAMLTokenIssuerConfig class since
the variables accessed in the SAML20TokenIssuer class were private in the

b.      After doing that the exported class built. 

2.       According to the instructions I removed the rampart.mar modules
from the modules directory.

3.       According to the instructions I made a service.xml pointing to my
new class. 

a.       I already had the example service.xml for the default service which
had saml-issuer-config elements in it as well as the policy and some rampart
crypto and password handler info.


The default service.xml had no ‘operation’ element. I added the elements as
shown in the instructions. The yellow highlight below is the name of the new
class to issue the token. Without the ‘mar’ modules I have no idea how it
gets called but that’s another story!


Of course it did not work. I got an unsupported major minor version in the
Tomcat window.


The instructions don’t really make sense anyways since it is the modules
that are telling what routines are accessed. The rampart.mar module seems
like it needs to stay and the rahas module points to the class the invokes
the token issuer. I tried various combinations of that approach and it also
failed. I also got an unsupported major minor version in the Tomcat window.


In short the instructions for implementing a custom STS service make no
sense to me and are too thin to know how to proceed when one has problems or
questions. These instructions have not changed as the project has updated
and maybe they are simply out of date (for example there is no mention of


1.        Has anyone actually implemented a custom STS in axis2/rampart

a.       If so did you need to have rampart and rahas mar files in the

                                                               i.      If so
did you need to modify them in any way?

                                                             ii.      If not
how does the axis2 architecture know when to call your custom

b.      Did you have to make a service xml?

c.       If so, how is it different than the service.xml needed for the
default implementation (where the token issued is a SAML2.0 token)?

d.      The instructions show a single-line saml-issuer-config value in the
‘service.xml’. How would you extend that to get the full xml parameter
description of all the saml-issuer-config elements?


Here is my service xml for the custom service based upon the service xml for
the default service and the instructions provided in the custom issuer


    <service name="STS_Username">   

        <module ref="rampart" />

        <module ref="addressing" />

        <module ref="rahas" />

        <operation name="IssueToken"

            <messageReceiver class="org.apache.rahas.STSMessageReceiver"/>


            <!--  --> Action mapping to accept RST requests -->





> </actionMapping>



            <parameter name="token-dispatcher-configuration">


                    <!--  --> Issuers. You may have many issuers. -->

class="com.lnihealth.sts.receiver.LNISAML2TokenIssuer" default="true">


okenType> </tokenType>







        <parameter name="saml-issuer-config">


                <issuerName>LNI SAML Token Service</issuerName>










                <!--  30 days -->



                <addRequestedAttachedRef />

                <addRequestedUnattachedRef />



                   Key computation mechanism

                   1 - Use Request Entropy

                   2 - Provide Entropy

                   3 - Use Own Key





                   proofKeyType element is valid only if the keyComputation
is set to 3

                   i.e. Use Own Key


                   Valid values are: EncryptedKey & BinarySecret




                    <service alias="service">*</service>





[Policy xml follows with rampart config info shown below]


              <!--  These elements are clearly rampart specific and are not
part of WS-Policy or WS-SecurePolicy -->




              <!--  End of rampart specific area. This stuff should be
removed when exchanging policies -->


[closing of document]


I am fully baffled! Really appreciate any help to get this off the ground!





From: Martin Gainty [] 
Sent: Tuesday, October 30, 2012 3:06 PM
Subject: RE: Configure Rampart STS


env is a SOAPEnvelope constructed from the input MessageContext
SOAPEnvelope env = TrustUtil.createSOAPEnvelope(inMsgCtx
a parent OMElement is constructed from env.getBody()

if addRequestedAttachedRef is true the AttachedRef OMElement gets

if (config.addRequestedAttachedRef) {
                                     wstVersion,   //Rahas version (defaults
to 1)
                                        rstrElem,  //OMElement
                    "#" + assertion.getID(),   //link within document using
GUID constructed with UUIDGenerator.getUUID()
RahasConstants.TOK_TYPE_SAML_20); //value is"

if addRequestedUnattachedRef is true the UnattachedRef OMElement gets

            if (config.addRequestedUnattachedRef) {
                TrustUtil.createRequestedUnattachedRef(wstVersion, //Rahas
version (defaults to 1)
                                         rstrElem, //OMElement
                               assertion.getID(), // GUID constructed with
  RahasConstants.TOK_TYPE_SAML_20); //value is"

rstrElem (2nd arg) is a constructed OMElement constructed here
 public static OMElement
            createRequestSecurityTokenResponseElement(int version,
                                                      OMElement parent)
throws TrustException {
        return createOMElement(parent,
                               getWSTNamespace(version),    //for 1 version
                               RahasConstants.WST_PREFIX);   //wst

youve got a SecurityTokenResponse coming back inlined in Document with
if not in the document call TrustUtil.createRequestedUnAttachedRef

personally i prefer XML declarators to accomplish the same objective that
way you can see the token-dispatcher-configuration being sent in e.g.
services.xml would contain

&lt;module ref="rampart" /&gt;

&lt;operation name="IssueToken"

    &lt;!-- Action mapping to accept RST requests --&gt;

    &lt;parameter name="token-dispatcher-configuration"&gt;
        &lt;!-- Issuers. You may have many issuers. --&gt;
        &lt;issuer class="org.custom.MyIssuer" default="true"&gt;

Martin Gainty 
Jogi és Bizalmassági kinyilatkoztatás/Verzicht und
Vertraulichkeitanmerkung/Note de déni et de confidentialité


Ez az üzenet bizalmas.  Ha nem ön az akinek szánva volt, akkor kérjük, hogy
jelentse azt nekünk vissza. Semmiféle továbbítása vagy másolatának készítése
nem megengedett.  Ez az üzenet csak ismeret cserét szolgál és semmiféle jogi
alkalmazhatósága sincs.  Mivel az electronikus üzenetek könnyen
megváltoztathatóak, ezért minket semmi felelöség nem terhelhet ezen üzenet
tartalma miatt.

Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene
Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte
Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht
dient lediglich dem Austausch von Informationen und entfaltet keine
rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von
E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen.

Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le
destinataire prévu, nous te demandons avec bonté que pour satisfaire
informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie
de ceci est interdite. Ce message sert à l'information seulement et n'aura
pas n'importe quel effet légalement obligatoire. Étant donné que les email
peuvent facilement être sujets à la manipulation, nous ne pouvons accepter
aucune responsabilité pour le contenu fourni.



Subject: RE: Configure Rampart STS
Date: Tue, 30 Oct 2012 13:56:33 -0400



Thanks, but what is unclear is what else exists? (maybe nothing?), and what
are these: <addRequestedAttachedRef /> <addRequestedUnattachedRef />

In many of the examples the ‘saml-issuer-config’ had nothing in it. Was it
implied that the user is to fill it in?




From: Martin Gainty [] 
Sent: Tuesday, October 30, 2012 1:24 PM
Subject: RE: Configure Rampart STS


 MG>Quick answer inlined

From: Brian Reinhold [] 
Sent: Tuesday, October 30, 2012 10:38 AM
Subject: Configure Rampart STS


I am trying to understand how to configure my own STS service to generate a
custom SAML token. The instructions are confusing.


First it states to remove the default rampart.mar from the modules. In my
modules there is both a rampart.mar and a rahas.mar.

Then it states to create a service.xml pointing to one’s custom
implementation of the TokenIssuer interface. The contents of the example
service.xml provided looks very similar to the contents of the rahas.mar
module and bears no resemblance to the rampart.mar. 

In addition, there is a ‘saml-issuer-config’ value of the configuration
element. I have no idea what that element represents. Do I need to make some
type of file containing configuration parameters, and if I do, what are the
elements that go in it?  Has anybody ever done this? Do I have to play with
the axis.xml?


MG>only to add in the module name e.g. <module ref="rampart"/>

MG>you will want to configure services.xml in WEB-INF\services only


Any insight would be greatly appreciated!








Here is some stuff I found no documentation on with respect to


        <parameter name="saml-issuer-config">




MG>alias for the provided key you will need the alias to export the cert out
of the pfx e.g.

MG>keytool -exportcert -alias AlienAlias -keystore steve.jks -keypass steve
-storepass steve -file steve.cert





MG>safe to stay with JKS although easy enough to convert a p12 format to jks


MG>name of the Java Key file..the absolute path must be known in order to
configure a HTTPS connector 


MG>password to the keystore file




MG>lifetime of SAML token default to 5 min


MG>keysize in bits used with generation step e.g. keytool -genkey -keysize

MG>the longer the keysize the more difficult to crack by brute force

                <addRequestedAttachedRef />

                <addRequestedUnattachedRef />


MG><!-- Key computation mechanism 1 - Use Request Entropy 2 - Provide
Entropy 3 - Use Own Key -->


MG><!-- proofKeyType element is valid only if the keyComputation is set to 3
i.e. Use Own Key Valid values are: EncryptedKey & 
MG> BinarySecret -->


                    <service alias="service">*</service>

MG><!-- The service name and the alias of the trusted cert to use -->
<service alias="bob">http://localhost:8080/axis2/services


MG>the alias is referenced by the trust-store lookup manager to find a
key-entity that was previously inserted its own truststore





There are several xml elements I cannot find documented anywhere except for
the cryptoProperties. Some are easier to GUESS; but it would be nice not to
guess. The bigger question is what other parameters exist that I don’t see
in this example? In general, the documentation on the xml part of
Axis2/Rampart is lacking yet is so critical to its use. Does anyone have all
the options one can place into the service.xmls and other xml config files
(where ever they may be) documented?


MG>Brian the saml-issuer-config elements are well documented at the WS02
site url


MG>let me know if you have any questions or concerns





View raw message