axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Gainty <mgai...@hotmail.com>
Subject RE: Configure Custom Rampart STS
Date Wed, 31 Oct 2012 17:28:27 GMT

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
repackage
and 
redeploy

Martin 
______________________________________________ 


To: java-dev@axis.apache.org; rtercerol@gmail.com
Subject: RE: Configure Custom Rampart STS
Date: Wed, 31 Oct 2012 13:10:58 -0400

Okay, I believe that I have followed the very limited instructions on how to implement a custom
STS service given at http://axis.apache.org/axis2/java/rampart/setting-up-sts.html. 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 SAMLTokenIssuerConfig.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 rahas.mar). 1.        Has anyone
actually implemented a custom STS in axis2/rampart 1.6.2?a.       If so did you need to have
rampart and rahas mar files in the modules?                                              
                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 implementation?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
documentation     <service name="STS_Username">           <module ref="rampart" />
       <module ref="addressing" />        <module ref="rahas" />         <operation
name="IssueToken" mep="http://www.w3.org/2006/01/wsdl/in-out">            <messageReceiver
class="org.apache.rahas.STSMessageReceiver"/>             <!--  --> Action mapping
to accept RST requests -->            <actionMapping>http://schemas.xmlsoap.org/ws/2005/02/trust/RST/SCT</actionMapping>
           <actionMapping>http://schemas.xmlsoap.org/ws/2005/02/trust/RST/Issue</actionMapping>
           <actionMapping>http://schemas.xmlsoap.org/ws/2005/02/trust/RST/Renew</actionMapping>
           <actionMapping>http://schemas.xmlsoap.org/ws/2005/02/trust/RST/Cancel</actionMapping>
           <actionMapping>http://schemas.xmlsoap.org/ws/2005/02/trust/RST/SCT/Cancel</actionMapping>
           <actionMapping>http://schemas.xmlsoap.org/ws/2005/02/trust/RST/Validate</actionMapping>
            <parameter name="token-dispatcher-configuration">                <token-dispatcher-configuration>
                   <!--  --> Issuers. You may have many issuers. -->            
       <issuer class="com.lnihealth.sts.receiver.LNISAML2TokenIssuer" default="true">
                       <configuration type="parameter">saml-issuer-config</configuration>
                       <tokenType>http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0</tokenType>
                   </issuer>                </token-dispatcher-configuration>
           </parameter>         </operation>         <parameter name="saml-issuer-config">
           <saml-issuer-config>                <issuerName>LNI SAML Token Service</issuerName>
               <issuerKeyAlias>service</issuerKeyAlias>                <issuerKeyPassword>apache</issuerKeyPassword>
               <cryptoProperties>                    <crypto provider="org.apache.ws.security.components.crypto.Merlin">
                       <property name="org.apache.ws.security.crypto.merlin.keystore.type">JKS</property>
                       <property name="org.apache.ws.security.crypto.merlin.file">service.jks</property>
                       <property name="org.apache.ws.security.crypto.merlin.keystore.password">apache</property>
                   </crypto>                </cryptoProperties>              
 <!--  30 days -->                <timeToLive>2592000</timeToLive>     
          <keySize>256</keySize>                <addRequestedAttachedRef />
               <addRequestedUnattachedRef />                 <!--               
   Key computation mechanism                   1 - Use Request Entropy                   2
- Provide Entropy                   3 - Use Own Key                -->                <keyComputation>2</keyComputation>
                <!--                   proofKeyType element is valid only if the keyComputation
is set to 3                   i.e. Use Own Key                    Valid values are: EncryptedKey
& BinarySecret                -->                <proofKeyType>BinarySecret</proofKeyType>
               <trusted-services>                    <service alias="service">*</service>
               </trusted-services>            </saml-issuer-config>        </parameter>
[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 -->
             <ramp:RampartConfig xmlns:ramp="http://ws.apache.org/rampart/policy"> 
            <ramp:passwordCallbackClass>com.lnihealth.wan.receiver.binding.axis2.PasswordCallback</ramp:passwordCallbackClass>
             </ramp:RampartConfig>              <!--  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! Brian  From: Martin
Gainty [mailto:mgainty@hotmail.com] 
Sent: Tuesday, October 30, 2012 3:06 PM
To: java-dev@axis.apache.org; rtercerol@gmail.com
Subject: RE: Configure Rampart STS env is a SOAPEnvelope constructed from the input MessageContext
SOAPEnvelope env = TrustUtil.createSOAPEnvelope(inMsgCtx .getEnvelope().getNamespace().getNamespaceURI());
a parent OMElement is constructed from env.getBody()

if addRequestedAttachedRef is true the AttachedRef OMElement gets constructed 

if (config.addRequestedAttachedRef) {
                TrustUtil.createRequestedAttachedRef(
                                     wstVersion,   //Rahas version (defaults to 1)
                                        rstrElem,  //OMElement TrustUtil.createRequestSecurityTokenResponseElement(wstVersion,env.getBody());
                    "#" + assertion.getID(),   //link within document using GUID constructed
with UUIDGenerator.getUUID()
RahasConstants.TOK_TYPE_SAML_20); //value is http://docs.oasis-open.org/wss/" +"oasis-wss-saml-token-profile-1.1#SAMLV2.0";
            }

if addRequestedUnattachedRef is true the UnattachedRef OMElement gets constructed 

            if (config.addRequestedUnattachedRef) {
                TrustUtil.createRequestedUnattachedRef(wstVersion, //Rahas version (defaults
to 1)
                                         rstrElem, //OMElement TrustUtil.createRequestSecurityTokenResponseElement(wstVersion,env.getBody());
                               assertion.getID(), // GUID constructed with UUIDGenerator.getUUID()
  RahasConstants.TOK_TYPE_SAML_20); //value is http://docs.oasis-open.org/wss/" +"oasis-wss-saml-token-profile-1.1#SAMLV2.0";
            }

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 xmlns:wst="http://schemas.xmlsoap.org/ws/2005/02/trust"
                               RahasConstants.LocalNames.REQUEST_SECURITY_TOKEN_RESPONSE,
 //RequestSecurityTokenResponse
                               RahasConstants.WST_PREFIX);   //wst
    }

youve got a SecurityTokenResponse coming back inlined in Document with TrustUtil.createRequestedAttachedRef
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"
        mep="http://www.w3.org/ns/wsdl/in-out"&gt;
    &lt;messageReceiver
            class="org.apache.rahas.STSMessageReceiver"/&gt;

    &lt;!-- Action mapping to accept RST requests --&gt;
    &lt;actionMapping&gt;http://schemas.xmlsoap.org/ws/2005/02/trust/RST/SCT&lt;/actionMapping&gt;
    &lt;actionMapping&gt;http://schemas.xmlsoap.org/ws/2005/02/trust/RST/Issue&lt;/actionMapping&gt;
    &lt;actionMapping&gt;http://schemas.xmlsoap.org/ws/2005/02/trust/RST/Renew&lt;/actionMapping&gt;
    &lt;actionMapping&gt;http://schemas.xmlsoap.org/ws/2005/02/trust/RST/Cancel&lt;/actionMapping&gt;
    &lt;actionMapping&gt;http://schemas.xmlsoap.org/ws/2005/02/trust/RST/SCT/Cancel&lt;/actionMapping&gt;
    &lt;actionMapping&gt;http://schemas.xmlsoap.org/ws/2005/02/trust/RST/Validate&lt;/actionMapping&gt;

    &lt;parameter name="token-dispatcher-configuration"&gt;
        &lt;token-dispatcher-configuration&gt;
        &lt;!-- Issuers. You may have many issuers. --&gt;
        &lt;issuer class="org.custom.MyIssuer" default="true"&gt;
                &lt;configuration
                        type="parameter"&gt;saml-issuer-config&lt;/configuration&gt;
                &lt;tokenType&gt;http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV1.1&lt;/tokenType&gt;
            &lt;/issuer&gt;
        &lt;/token-dispatcher-configuration&gt;
    &lt;/parameter&gt;

&lt;/operation&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.

From: brianreinhold@lampreynetworks.com
To: java-dev@axis.apache.org; rtercerol@gmail.com
Subject: RE: Configure Rampart STS
Date: Tue, 30 Oct 2012 13:56:33 -0400Martin, 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? Brian From: Martin Gainty [mailto:mgainty@hotmail.com] 
Sent: Tuesday, October 30, 2012 1:24 PM
To: java-dev@axis.apache.org; rtercerol@gmail.com
Subject: RE: Configure Rampart STS  MG>Quick answer inlinedFrom: Brian Reinhold [mailto:brianreinhold@lampreynetworks.com]

Sent: Tuesday, October 30, 2012 10:38 AM
To: java-dev@axis.apache.org; rtercerol@gmail.com
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! Thanks, Brian PS Here is some stuff I found no documentation
on with respect to saml-issuer-config         <parameter name="saml-issuer-config">
           <saml-issuer-config>                <issuerName>SAMPLE_STS</issuerName>
               <issuerKeyAlias>service</issuerKeyAlias>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   
            <issuerKeyPassword>apache</issuerKeyPassword>                <cryptoProperties>
                   <crypto provider="org.apache.ws.security.components.crypto.Merlin">
                       <property name="org.apache.ws.security.crypto.merlin.keystore.type">JKS</property>MG>safe
to stay with JKS although easy enough to convert a p12 format to jks                     
  <property name="org.apache.ws.security.crypto.merlin.file">service.jks</property>MG>name
of the Java Key file..the absolute path must be known in order to configure a HTTPS connector
                        <property name="org.apache.ws.security.crypto.merlin.keystore.password">apache</property>MG>password
to the keystore file                    </crypto>                </cryptoProperties>
               <timeToLive>864000000000</timeToLive>MG>lifetime of SAML token
default to 5 min                <keySize>256</keySize>MG>keysize in bits used
with generation step e.g. keytool -genkey -keysize 2048 MG>the longer the keysize the more
difficult to crack by brute force                <addRequestedAttachedRef />       
        <addRequestedUnattachedRef />                <keyComputation>3</keyComputation>MG><!--
Key computation mechanism 1 - Use Request Entropy 2 - Provide Entropy 3 - Use Own Key -->
               <proofKeyType>BinarySecret</proofKeyType>MG><!-- proofKeyType
element is valid only if the keyComputation is set to 3 i.e. Use Own Key Valid values are:
EncryptedKey & 
MG> BinarySecret -->                <trusted-services>                    <service
alias="service">*</service>MG><!-- The service name and the alias of the trusted
cert to use --> <service alias="bob">http://localhost:8080/axis2/servicesMG>/STS</service>MG>the
alias is referenced by the trust-store lookup manager to find a key-entity that was previously
inserted its own truststore                </trusted-services>            </saml-issuer-config>
       </parameter> 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 urlMG>https://svn.wso2.org/repos/wso2/carbon/platform/trunk/dependencies/rampart/1.6.1-wso2v4/modules/rampart-trust/sts-aar-resources/saml-issuer-config.xml

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

MG>Martin    		 	   		  
Mime
View raw message