axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brian Reinhold" <brianreinh...@lampreynetworks.com>
Subject RE: Configure Custom Rampart STS
Date Thu, 01 Nov 2012 12:21:40 GMT
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!

 

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 -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
<http://schemas.xmlsoap.org/ws/2005/02/trust/RST/SCT%3c/actionMapping>
</actionMapping>

 
<actionMapping>http://schemas.xmlsoap.org/ws/2005/02/trust/RST/Issue
<http://schemas.xmlsoap.org/ws/2005/02/trust/RST/Issue%3c/actionMapping>
</actionMapping>

 
<actionMapping>http://schemas.xmlsoap.org/ws/2005/02/trust/RST/Renew
<http://schemas.xmlsoap.org/ws/2005/02/trust/RST/Renew%3c/actionMapping>
</actionMapping>

 
<actionMapping>http://schemas.xmlsoap.org/ws/2005/02/trust/RST/Cancel
<http://schemas.xmlsoap.org/ws/2005/02/trust/RST/Cancel%3c/actionMapping>
</actionMapping>

 
<actionMapping>http://schemas.xmlsoap.org/ws/2005/02/trust/RST/SCT/Cancel
<http://schemas.xmlsoap.org/ws/2005/02/trust/RST/SCT/Cancel%3c/actionMapping
> </actionMapping>

 
<actionMapping>http://schemas.xmlsoap.org/ws/2005/02/trust/RST/Validate
<http://schemas.xmlsoap.org/ws/2005/02/trust/RST/Validate%3c/actionMapping>
</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#S
AMLV2.0
<http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0</t
okenType> </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</proper
ty>

                    </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.Passwor
dCallback</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&l
t;/actionMapping&gt;
 
&lt;actionMapping&gt;http://schemas.xmlsoap.org/ws/2005/02/trust/RST/Renew&l
t;/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/Can
cel&lt;/actionMapping&gt;
 
&lt;actionMapping&gt;http://schemas.xmlsoap.org/ws/2005/02/trust/RST/Validat
e&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 -0400

Martin,

 

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 inlined

From: 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</proper
ty>

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/services

MG>/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 url

MG>https://svn.wso2.org/repos/wso2/carbon/platform/trunk/dependencies/rampar
t/1.6.1-wso2v4/modules/rampart-trust/sts-aar-resources/saml-issuer-config.xm
l

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

MG>Martin

 

 

 


Mime
View raw message