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 Thu, 01 Nov 2012 14:53:52 GMT

Both SamlTokenIssuer and SamlTokenIssuerConfig are classes which belong to rampart-trust module...the
pom.xml should look like

   <groupId>org.apache.rampart</groupId>
    <artifactId>rahas</artifactId>
    <packaging>mar</packaging>
    <version>${rahas.mar.version}</version

so to compile the rahas module I first compile then package with
mvn -e -X compile
mvn -e -X package

should result in \target\rahas-${rahas.mar.version}.mar

and should contain the rahas classes
org.apache.rahas.impl.SAMLTokenIssuer
org.apache.rahas.impl.SAMLTokenIssuerConfig

which you can now deploy to $CATALINA_HOME\webapps\Axis2Webapp\WEB-INF\modules

be sure to update modules.list
use your Axis2 admin screen to engage rahas module to your service AAR
be sure to activate afterwards

let us know if you have any problem
Martin Gainty 
______________________________________________ 
Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité

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 Custom Rampart STS
Date: Thu, 1 Nov 2012 08:21:40 -0400

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 token2.       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! Thanks, Brian 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 [mailto:mgainty@hotmail.com]

Sent: Wednesday, October 31, 2012 1:28 PM
To: java-dev@axis.apache.org; rtercerol@gmail.com
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
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 -0400Okay, 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