Thursday Jul 16, 2009

I Want Web Services Security To Work With One Instance of OpenSSO

Securing web services communications using OpenSSO entails embedding security information within the SOAP request sent to the web service provider (WSP), and within the response returned to the web service consumer (WSC). The communications may then securely pass through multiple intermediaries (firewalls and load balancers, for example) before reaching its intended receiver. The following sections illustrate how to configure and test secure web services communications using OpenSSO and included samples.

In this simple scenario, the message security is achieved using an instance of OpenSSO that communicates with a security agent deployed on both the WSC and WSP sides. The agent profiles for the deployment are configured using OpenSSO. The following procedures illustrate how to configure for web services security and test the configurations using the OpenSSO Stock Quote Service sample.

The first steps are to install three instances of Glassfish Application Server to host the WSC, the WSP and OpenSSO respectively. (Alternately, you can install one Glassfish instance and configure three different domains to host the WSC, the WSP and OpenSSO.) When finished with Glassfish, install OpenSSO. Instructions to install Glassfish and OpenSSO can be found in this (admittedly old but still valid with more recent downloads) blog entry or in the official documentation for Glassfish and OpenSSO. After completing these installations, proceed down the following list of procedures.

Installing a Web Services Security Agent

Follow this procedure to install each security agent with the Express Build 8 installer (not yet released). Before Express Build 8, use the old installer.
  1. Create a text file that contains the agentAuth password in clear text and save it.
    Configured out of the box, agentAuth is an agent profile with permission to read other configured agent profiles including the default wsc, wsp and SecurityTokenService. The agentAuth password is changeit.
  2. Download openssowssproviders.zip.
  3. Create a directory to which you will inflate the ZIP.
    % mkdir /tmp/wssunzip (or \\wssunzip on Windows)
  4. Unzip openssowssproviders.zip to the directory.
  5. Stop the Glassfish instance on which the agent is to be installed.
  6. Begin the installation with one of the following steps.
    • On UNIX and Linux, change to the /tmp/wssunzip/bin directory and run chmod 755 wssagentadmin. Following that, run ./wssagentadmin --install or ./wssagentadmin --custom-install.
    • On Windows, change to the \\wssunzip\\bin directory and run wssagentadmin.bat --install or wssagentadmin.bat --custom-install.
    Both options install the agent but --custom-install allows you to specify the application server instance name whereas the --install assumes the instance name to be server.
  7. Review the license information, if applicable.
  8. Enter the absolute path of the application server domain configuration directory.
  9. Enter the application server instance name if you ran the installer with the --custom-install option.
    In the case of Sun Application Server Enterprise Edition, a domain can have more than one application server instance so enter the name of the application server instance in which you are installing the agent.
  10. Enter the OpenSSO deployment URL using the format protocol://host:port/deployURI.
    protocol is either http or https; host is the fully qualified domain name of the machine on which OpenSSO is running and deployURI is the OpenSSO deployment URI; by default, opensso.
  11. Enter agentAuth, the user with permission to read the agent profiles.
  12. Enter the path to the agentAuth password file created at the beginning of this procedure.
  13. Review the summary and choose Continue with Installation to begin the process.
  14. Restart the Application Server instance or domain after installation is complete.

Adding Java Security Permissions

If the Glassfish Security Manager is enabled, you must add Java security permissions to all domains used in this deployment. If, for example, the WSC and WSP are deployed in one domain, edit only one server.policy file for the both.
  1. Append the Java security permissions defined in /tmp/wssunzip/config/OpenSSOJavaPermissions.txt to the server.policy file of the specific Application Server domain.
    Each Application Server domain has its own standard J2SE policy file named server.policy located in the /ApplicationServer-install/domains/domain-name/config directory.
  2. Restart the Application Server instance.

Deploying the Web Service Client and Web Service Provider Application Sample

The web services security sample contains the /tmp/wssunzip/samples/glassfish/StockQuoteClient and /tmp/wssunzip/samples/glassfish/StockService directories for the client and provider respectively. A /tmp/wssunzip/samples/glassfish/glassfish.properties file contains the configuration properties for Glassfish.
Deploying the Web Service Client Sample
  1. Create a password file for the Glassfish administrator.
    The password file should have read permissions and the line AS_ADMIN_password=password
  2. Edit glassfish.properties as follows: glassfish.home = WSC Glassfish installation directory (for example, /export/glassfishv2ur2/glassfish) glassfish.host = WSC Host where glassfish is installed (for example, opensso.sun.com) glassfish.passwordfile = path to Glassfish administrator password file (for example, /tmp/GFadmin_passwd)
  3. Set JAVA_HOME to JDK1.5 or 1.6 and ensure java and javac are in the PATH.
  4. Replace localhost and 8080 in the StockQuoteClient/src/java/com/samples/GetQuote.java and StockQuoteClient/src/java/com/samples/SOAPMessage.java files with the fully qualified domain name and port to which the web service provider was deployed.
    localhost and 8080 are the default OpenSSO values. These files would need modification if you changed the values for the web service provider during installation.
  5. Change to the StockQuoteClient directory and run WSC-ApplicationServer-install/lib/ant/bin/ant all.
    This will build and deploy the Stock Quote Sample Client to the WSC Glassfish container.
Deploying the Web Service Provider Sample
  1. Create a password file for the Glassfish administrator.
    The password file should have read permissions and the line AS_ADMIN_password=password
  2. Edit glassfish.properties as follows: glassfish.home = WSP Glassfish installation directory (for example, /export/glassfishv2ur2/glassfish) glassfish.host = WSP Host where glassfish is installed (for example, opensso.sun.com) glassfish.passwordfile = path to Glassfish administrator password file (for example, /tmp/GFadmin_passwd)
  3. Set JAVA_HOME to JDK1.5 or 1.6 and ensure java and javac are in the PATH.
  4. Change to the StockService directory and run WSP-ApplicationServer-install/lib/ant/bin/ant all.
    This will build and deploy the Stock Quote Sample Service to the WSP Glassfish container.

Creating the WSC, WSP and STS Agent Profiles Using OpenSSO

The agent profiles for a WSC (wsc), a WSP (wsp), and a Security Token Service (SecurityTokenService) are created when OpenSSO is installed. These can be used with the sample.
Configure the WSC Agent Profile
  1. Login to the OpenSSO console as the administrator; by default, amadmin.
  2. Click the Access Control tab.
  3. Click the top level realm.
  4. Under the Agents tab, click Web Service Client.
  5. OPTIONAL: Click New to create the WSC agent profile if you do not see the default wsc in the table.
    1. Enter wsc as the name of the agent profile.
    2. Define values for any required fields.
    3. Click Save.
  6. Click wsc from the table to access the profile.
  7. Select the appropriate Security Mechanism.
    If you select STSSecurity as Security Mechanism, the WSC is requesting that the OpenSSO Security Token Service (STS) generate a token to secure the request to the WSP. See To Configure the STS Agent Profile to create a profile for the Security Token Service.
  8. Check Is Request Signed.
  9. Check Preserve Security Headers in Message.
  10. Specify http://wsp-host-name:portnumber/StockService/StockService as the Web Service End Point.
  11. Save the changes.
  12. Click Back to Main Page.
Configure the Security Token Service Agent Profile
If you did not select STSSecurity as the Security Mechanism in To Configure the WSC Agent Profile, skip this procedure.
  1. Under the Agents tab, click STS Client.
  2. OPTIONAL: Click New to create the Security Token Service agent profile if you do not see the default SecurityTokenService in the table.
    1. Enter SecurityTokenService as the name of the agent profile.
    2. Define values for any required fields.
    3. Click Save.
  3. ClickSecurityTokenService from the table to access the profile.
  4. Select the appropriate Security Mechanism.
  5. Enter openssoserver_protocol://openssoserver_host:port/openssoserver_deploy_uri/sts as the Security Token Service End Point.
  6. Enter openssoserver_protocol://openssoserver_host:port/openssoserver_deploy_uri/sts/mex as Security Token Service MEX End Point.
  7. Save the changes.
  8. Click Back to Main Page.
Configure the WSP Agent Profile
  1. Under the Agents tab, click Web Service Provider.
  2. OPTIONAL: Click New to create the WSP agent profile if you do not see the default wsp in the table.
    1. Enter wsp as the name of the agent profile.
    2. Define values for any required fields.
    3. Click Save.
  3. Click wsp from the table to access the profile.
  4. Select all Security Mechanism choices.
  5. Check Is Request Signature Verified.
  6. Check Preserve Security Headers in Message.
  7. Specify http://wsp-host-name:portnumber/StockService/StockService as the Web Service End Point.
  8. Save the changes.
  9. Click Back to Main Page.
Review the Agent Authenticator Profile
  1. Under the Agents tab, click Agent Authenticator.
  2. Click agentAuth.
  3. Confirm that wsp, wsc, and SecurityTokenService have been added to the Selected list under the Agent Profiles allowed to Read attribute.
    If not, add them into the list and save the changes.
  4. Log out of the OpenSSO console.

Testing the Sample

  1. Access the stock quote client page at http://wsc-host-name:portnumber/StockQuoteClient/index.jsp.
    The browser will be redirected to the OpenSSO Authentication Service.
  2. Enter the user name and password of an existing OpenSSO user.
    Upon successful authentication, the browser is redirected back to the Stock Quote Service.
  3. Enter "JAVA" (or any other stock symbol) and click Get Quote.
    Stock quote information for the entered symbol is displayed.

And now that you've tested your web services security, check out Bow Wow Wow's video for I Want Candy.


Friday Mar 20, 2009

Heebie Jeebies! You CAN Encrypt Data in a Secure Attribute Exchange

I just posted an article documenting how to encrypt data when using the Secure Attribute Exchange (also known as Virtual Federation) gateway. It contains configuration procedures and tips on how to use the com.sun.identity.sae.api package. You can find this article on the doc wiki.

And don't forget to remember that Deployment Example: SAML v2 Using Sun OpenSSO Enterprise 8.0 also has information on configuring and using the Secure Attribute Exchange gateway.

Now let's reach waaaaaay back - almost eighty years back! Sure the Andrews Sisters were popular but they lifted what they did from the under-appreciated Boswell Sisters. Almost ten years before the Andrews ladies had their biggest hits, Connie, Martha and Vet had a huge harmonic hit with Heebie Jeebies (amongst others). And the Boswells played their own instruments and did their own production. What a bunch of gals!

Friday Jan 16, 2009

OpenSSO Security Product of the Year: A Cool Place to Be

If you haven't seen Pat's blog entry then you might not know that OpenSSO Enterprise won developer.com Security Product of the Year 2009. (2009? Whatever.) Congratulations to all coding peeps, doc nerds, quality analyzers, marketing gurus, virtual architects, and repeat voters. It's a cool place to be.

And if you've already seen the news, go to other Cool Places with Sparks and Jane Weidlin (of The Go-Go's). Very rare and very 80s.

NOTE: Really into this song? Search for the Sparks and the Go-Go's live versions. The Sparks video is from MTV in its heyday and is excellent; the Go-Go's not so much although it is interesting to hear it sung by Belinda Carlisle in 2006!

Tuesday Jan 13, 2009

Use SOAP 1.1 with OpenSSO Security Token Service

OpenSSO Enterprise 8.0 contains a Security Token Service. The Security Token Service verifies the credentials in a request presented by a web services client and, in response, issues a security token to provide proof that the client has authenticated with the Security Token Service. The web services client presents the security token to the web service which verifies that it was issued by a trusted Security Token Service. SOAP enables the exchange of these messages using a variety of underlying protocols. Out of the box, the Security Token Service supports SOAP 1.2 as a binding, a formal set of rules for transporting the messages. In order to enable SOAP 1.1 as a binding, make the following changes to before deploying the OpenSSO WAR.
  1. Download and unzip opensso.zip.
  2. Extract the contents of opensso.war using the jar command.
  3. Change into the WEB-INF/wsdl directory.
  4. Replace the default famsts.wsdl with the modified famsts.wsdl available here.

    Backup the original famsts.wsdl.
  5. Change into the WEB-INF directory.
  6. Replace the default sun-jaxws.xml with the modified sun-jaxws.xml available here.

    Backup the original sun-jaxws.xml.
  7. Modify the web.xml also located in the WEB-INF directory by adding the following two entries to the file as positioned below.

    
    <url-pattern>/sts/mex</url-pattern>
    </servlet-mapping>
    
    <servlet-mapping>
          <servlet-name>sts</servlet-name>
          <url-pattern>/sts/soap11</url-pattern>
      </servlet-mapping>
     
      <servlet-mapping>
            <servlet-name>sts</servlet-name>
            <url-pattern>/sts/mexsoap11</url-pattern>
      </servlet-mapping>
     
    <session-config>
       <session-timeout>60</session-timeout>
    </session-config>
    
  8. Archive a modified opensso.war, deploy it as usual and OpenSSO will be ready to use SOAP 1.1 as a binding for the Security Token Service.

Keeping in the SOAP mode, here's the Buggles performing their 1980 hit Clean Clean.

Wednesday Aug 13, 2008

Supported Security Tokens and Mr. Rock & Roll

The OpenSSO Security Token Service was developed from the WS-Trust protocol which defines extensions to the WS-Security specification for issuing and exchanging security tokens and establishing and accessing the presence of trust relationships. The Security Token Service is hosted as a servlet endpoint and coordinates security based interactions between a WSC and a WSP. The Security Token Service:

  • Issues, renews, cancels, and validates security tokens.
  • Allows customers to write their own plug-ins for different token implementations and for different token validations.
  • Provides a WS-Trust based API for client and application access.
  • Provides security tokens including Kerberos, Web Services-Interoperability Basic Service Profile (WS-I BSP), and Resource Access Control Facility (RACF).

Here is some information on supported security tokens in OpenSSO.

Security Token Service Supported Tokens

Tokens that can be authenticated:

  • UserName
  • X509
  • SAML 1.1
  • SAML 2.0
  • Kerberos

Tokens that can be issued:

  • UserName
  • X509
  • SAML 1.1
  • SAML 2.0

End user tokens that can be converted or validated out of the box:

  • OpenSSO SSOToken to SAML 1.1 or SAML 2.0 token
  • SAML 1.1 or SAML 2.0 token to OpenSSO SSOToken

Additionally, end user tokens can be converted or validated after customization. In this case, the new token is an On Behalf Of token (based on the WS-Trust protocol element) carried in the WS-Trust request as part of the SOAP body and not as an authentication token carried as part of the SOAP header. Custom tokens can also be created and sent On Behalf Of an end user token for conversion or validation by Security Token Service. To do this, implement the com.sun.identity.wss.sts.ClientUserToken interface and put the implemented class name in AMConfig.properties on the client side and the global Security Token Service configuration using the OpenSSO console.

Web Services Security Framework Supported Tokens

Tokens that can be authenticated:

  • UserName
  • X509
  • SAML 1.1
  • SAML 2.0
  • Kerberos

Tokens that can be issued:

  • UserName (generated via STS or locally at WSC)
  • X509 (generated via the Security Token Service or locally at the WSC)
  • SAML 1.1 (generated via the Security Token Service or locally at the WSC)
  • SAML 2.0 (generated via the Security Token Service or locally at the WSC)
  • Kerberos (generated locally at the WSC)

After learning something new, now enjoy some music from Amy MacDonald. This is Mr. Rock & Roll.

About

docteger

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today