Friday Aug 14, 2009

The New OpenSSO Console Rip-Off

OK, it's not technically a rip-off but that's all I could come up with in the time allotted.

The team of OpenSSO engineers have been working on a new administration console. The plan is to release a beta version of the new console with OpenSSO Express Build 8. Although the trees that contribute to the nightly build and the Express 8 build have not yet been consolidated, portions of the new beta console are available for your perusal in the nightly build. Things will undoubtedly change before the actual release; the following information is so you can take a look at the direction we are going.

This new OpenSSO administration console is in beta and should only be used for test environments. Continue to use the standard OpenSSO administration console for real-time deployments.

After deploying opensso.war to a web container, login to OpenSSO as the administrator and enter protocol://machine.domain:port/deploy-uri/admin in the Location Bar of a browser to display the new console interface.

The Entitlements, Federation and Web Service Security tabs comprise the bulk of features currently in this new console. Accommodations have been made for these features by providing inline help displayed on the console screen. Additional documentation will be available after the beta release. Working With the Entitlements Service The Entitlements tab contains the new work flows for ease-of-use when creating new, and managing existing, policies for the new Entitlements Service. These features are only available in the beta administration console. You must choose the framework with which you will be creating policies for your resources. The options are the Policy Service using the standard administration console and the Entitlements Service using the beta administration console. Once the choice is made (by creating and saving a policy using one or the other), only that service (Entitlements or Policy) will be enabled. Migration of policies from previous versions of OpenSSO is not supported.

Using the Federation Work Flows The Federation tab contains the new work flows for ease-of-use when creating and registering entity providers for the Federation Service using the SAMLv2 protocol. These work flows are available in either the standard or beta administration console. If you create SAMLv2 entity providers using the work flows in the beta administration console, you manage the configurations using the standard administration console.

Using the Web Services Security Work Flows The Web Service Security tab contains the new work flows for ease-of-use in creating profiles to work with the Web Service Security framework. These work flows are available only in the beta administration console although profiles can also be created by manually configuring attributes using the standard administration console. You can create profiles in the beta console and manage them in the standard console.

Displaying Realms The intent with the beta administration console is to hide realms. If no realms are configured using the standard console, the applicable interface to switch realms will not be visible in the beta console, nor anything about referrals. If you create a realm using the standard console, realm and referral menu items are visible.

Now enjoy the greatly, soulful Laura Lee and her 1972 hit, Rip-Off.


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 May 01, 2009

Romanticizing the OpenSSO WSSAuth Authentication Module

The WS-Security specifies the Username Token Profile for providing basic authentication information. The profile describes how the UsernameToken element can be used as a means for communicating a user identifier and password between a web service provider (WSP) and web service client (WSC). The OpenSSO WSSAuth authentication module validates the credentials presented by the WSC using the UsernameToken profile.

The UsernameToken profile contains an element to present a hash of the user's password - the PasswordDigest element. Using this element adds security as the password is not exposed as clear text. The following steps show how to configure for authentication using the Username Token profile with a one way hash password.
  1. Login into the OpenSSO console as administrator.
  2. Navigate to Access Control -> / (Top Level Realm) -> Agents -> Web Service Client -> wsc
  3. Select UserName Token as the value of Security Mechanism.
    This uses the PasswordDigest option.
  4. Enable User Authentication Required to generate a user token.
  5. Change the Name and Password values for the Credential for User Token.
    This attribute contains the shared secrets used by the WSC to generate a user token. The password should be the same as the hashed password stored in the OpenSSO configuration data store. Use ldapsearch if the data store is Directory Server. NOTE: This step is for demonstration purposes only. In real deployments, the WSC and WSP would have a common agreement about their password storage policy.
  6. Navigate to Access Control -> / (Top Level Realm) -> Authentication.
  7. Create a new authentication chain named wssauthchain.
    See Configuring an Authentication Process Using the OpenSSO Enterprise Console.
  8. Click wssauthchain in the list of authentication chains.
  9. Add WSSAuth as the required Authentication Mechanism and click Save.
  10. Navigate to Access Control -> / (Top Level Realm) -> Agents -> Web Service Provider -> wsp
  11. Select UserName Token as the value of Security Mechanism and wssauthchain as the authentication chain.
  12. Click Save.

To test the configurations, use the stock quote sample included with the Web Services Security Agent. After attempting to access the sample's main page, the user is redirected to OpenSSO for authentication. After successfully authenticating, the user is redirected back to the main page. When the user clicks the Get Quote button, stock quote values are displayed and the authentication mechanism used is displayed; in this case, Username Token with digest option. Changing the security mechanism would result in the new security mechanism being displayed. When logging is enabled, the OpenSSO logs would also have the appropriate tokens.

More romanticizing with Combo Audio performing the indy version of their tune, Romanticide for this video cover. I thought it was the real deal because the 7" single I owned back then had no band picture. Still a great tune.

Unlike the version they rerecorded after signing with a major label. This cleaner version is okay but not the bomb that was dropped when they released the original. But at least there's a video!

Monday Feb 23, 2009

Keystores and Certificate Alias Foundations for Web Services Security

Keystores and certificate aliases are using by OpenSSO when securing (through signing and encryption) web service requests and responses for purposes of web services security. The default certificate alias used by the Security Token Service is test. The Security Token Service uses the keystore location, keypass and storepass from the central server configuration. This data is also used by the token implementation for signing the generating the security token. The agent profiles available for Web Services Security (WSCAgent, WSPAgent and STSAgent) uses either of the following keystores:
  • If the configuration property useDefaultStore is set to true, these profiles will use the keystore location, keypass and storepass defined by the AMConfig.properties file configured local to the WSC, WSP and STS client installs. (The WSC, WSP and STS client communicate with OpenSSO using openssoclientsdk.jar and AMConfig.properties.)
  • You can also define a custom keystore location, keypass and storepass when you configure the agent profiles directly using the OpenSSO console. These values take precedence over the values in the client side AMConfig.properties.

The PrivateKeyAlias and PublicKeyAlias can also be defined when you configure the profiles directly. You configure them for either the default or custom keystore. You can have different alias from same keystore. By default, the value is test since by default the keystore is the default keystore.

Now here's a clip of The Foundations singing Baby, Now That I've Found You.

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.

What's Going On with WSIT?

The Web Services Security feature of OpenSSO implements the Web Services Interoperability Technology (WSIT). WSIT is an open source implementation of the web services specifications (commonly referred to as WS-\*). The project was started by Sun Microsystems, and consists of Java API that allow developers to create web service clients and services that enables operations between the Java platform and clients and servers developed with the WS-\* specifications. WSIT provides implementations of the following specifications for interoperability with .NET 3.0.

  • WS-Metadata Exchange
  • WS-Transfer
  • WS-Reliable Messaging
  • WS-Reliable Messaging Policy
  • WS-Atomic Transaction
  • WS-Coordination
  • WS-Security 1.0 and 1.1
  • WS-Security Policy
  • WS-Trust
  • WS-Secure Conversation
  • WS-Policy
  • WS-Policy Attachment

While looking for information on WSIT, I found this great PDF file on developers.sun.com called the WSIT Tutorial. If you need to know what's going on with WSIT, this is the paper to read.

And if you just want to hear What's Going On by Marvin Gaye, this is the clip to click.

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