Tuesday Jan 19, 2010

Using OpenSSO with Microsoft Geneva Server

I just posted MICROSOFT® “GENEVA” SERVER AND SUN OPENSSO: ENABLING UNPRECEDENTED COLLABORATION ACROSS HETEROGENEOUS IT ENVIRONMENTS. This paper (written by another) focuses on Sun OpenSSO Enterprise and Microsoft Geneva Server — specifically, on their common support for the Security Assertion Markup Language (SAML) federation standard as a basis for interoperability. The paper:
  • Presents an overview of solutions and capabilities, both individual and interoperable solutions.
  • Describes the business benefits of interoperability between the two.
  • Shares detailed use cases demonstrating proven interoperability in real-world federation scenarios.
But before you leave, it's not Geneva, it's Vienna by Utravox.

Monday Feb 09, 2009

Deployment Example 2: SAE Expanded, Not Reduced

Some additional procedures have been made to the Secure Attribute Exchange (aka Virtual Federation) section of Deployment Example 2: SAML v2 Using Sun OpenSSO Enterprise 8.0. The section has been reorganized and changes made to 13.2 and 13.3, the identity provider and service provider configuration sections. You can see the new HTML version here on docs.sun.com tomorrow but you can download the new PDF from OpenSSO now.

And since SuperPat scoffs at my description of The Enemy as being old-school punk (pulling out his Coventry cred, no less) I decided to embed some real punk I happen to see back in the day (pulling out my CBGB cred, no less) from the Dead Boys. Check out Sonic Reducer.

Tuesday Jan 27, 2009

Customize an OpenSSO IDPAttributeMapper For Once

To implement a federated solution where the consumer of a service can select which attribute is sent from the identity provider to the service provider as an assertion write a custom IDPAttributeMapper . The getAttributes() method takes the OpenSSO SSOToken as one of its parameters. From this, you can determine who the end user is, pull the correct attributes for that user and return the values as an attribute list. The identity provider will take the attributes and send them to the service provider as part of a SAMLv2 assertion.

Once you've finished, check out the video for the Academy Award-winning song from the movie Once. Excellent film about two people Falling Slowly in love. The love segued into real life until last night when I read that Glen Hansard and Marketa Irglova were no longer a couple. Worse things have happened but they were a sweet couple in the film.

Friday Jan 23, 2009

Testing The Sweet OpenSSO SAMLv2 Name Identifiers

The SAMLv2 Name Identifier Management Profile documents how an identity provider and a service provider might inform each other of changes to the identifier that they reference when communicating about a particular identity. The various OpenSSO ManageNameID (MNI) JSP provide a way to change SAMLv2 name identifiers or terminate mappings between identity provider accounts and service provider accounts. For example, after establishing a name identifier for use between providers when referring to an identity in SAMLv2 communications, an identity provider may want to change the value and/or format. The identity provider will notify service providers of the change by sending them a ManageNameIDRequest. A service provider might also use this message type to register or change the SPProvidedID value (included when the underlying name identifier is used to communicate with it) or to terminate the use of a name identifier between itself and the identity provider.

Following is a procedure that can be used to test the profile using OpenSSO. In the example procedure, maple.sun.com is the identity provider and honey.sun.com is the service provider.

  1. Initiate single sign-on and account linking (federation) from the service provider side using http://honey.sun.com:80/opensso/saml2/jsp/spSSOInit.jsp?
    metaAlias=/sp&idpEntityID=maple.sun.com
    .

    spSSOInit.jsp is used to initiate single sign-on and federation on the service provider side. Because metaAlias and idpEntityID are defined, the request is created and sent to the identity provider. This links the two accounts and creates a name identifier to be used by the providers to refer to the identity during communications. Both providers keep the name identifier in the user's profile which makes the format persistent.
  2. Log in to the identity provider host machine and the service provider host machine as root.
  3. Run
    ldapsearch -h maple -D "cn=directory manager" -w password -p 389 -b "dc=sun,dc=com" "uid=\*" sun-fm-saml2-nameid-info sun-fm-saml2-nameid-infokey
    on each host machine to view the values for the sun-fm-saml2-nameid-info and sun-fm-saml2-nameid-infokey properties.

    • On the identity provider side, sun-fm-saml2-nameid-info will have a value similar to

      sun-fm-saml2-nameid-info=maple.sun.com|honey.sun.com|
      KFXSFabPdkOOhRpkkW8Aj5Etnq2o|maple.sun.com|
      urn:oasis:names:tc:SAML:2.0:nameid-format:persistent|
      null|honey.sun.com|IDPRole|false

      On the service provider side, sun-fm-saml2-nameid-info will have a value similar to

      sun-fm-saml2-nameid-info=honey.sun.com|maple.sun.com|
      KFXSFabPdkOOhRpkkW8Aj5Etnq2o|maple.sun.com|
      urn:oasis:names:tc:SAML:2.0:nameid-format:persistent|
      null|honey.sun.com|SPRole|false

      sun-fm-saml2-nameid-info is used to store all information related to the name identifier. The value is formatted as:

      hosted_entity_id|remote_entity_id|idp_nameid|
      idp_nameid_qualifier|idp_nameid_format|
      sp_nameid|sp_nameid_qualifier|
      hosted_entity_role|is_affiliation

      where

              hosted_entity_id    : entity id for this hosted entity
              remote_entity_id    : entity id for the remote entity
              idp_nameid          : name identifier for the IDP
              idp_nameid_qualifier: nameid qualifier for the IDP
              idp_nameid_format   : nameid format for the IDP
              sp_nameid           : name identifier for the SP/Affiliation
              sp_nameid_qualifier : nameid qualifier for the SP/Affiliation
              hosted_entity_role  : SPRole or IDPRole, useful when one entity could be IDP and SP at same time.
              is_affiliation      : true for affiliation, false otherwise 
      
    • On the identity provider side, sun-fm-saml2-nameid-infokey will have a value similar to

      sun-fm-saml2-nameid-infokey=maple.sun.com|honey.sun.com|
      KFXSFabPdkOOhRpkkW8Aj5Etnq2o

      On the service provider side, sun-fm-saml2-nameid-infokey will have a value similar to

      sun-fm-saml2-nameid-infokey=honey.sun.com|maple.sun.com|
      KFXSFabPdkOOhRpkkW8Aj5Etnq2o

      sun-fm-saml2-nameid-infokey is used to search an LDAP data store for better performance, when that type of data store is used. The user that binds to the LDAP data store must have read/write/search/compare permission to this attribute. You must also must make sure that the equality type index is added to the data store. The value is formatted as:

      hosted_entity_id|remote_entity_id|idp_nameid

      where

              hosted_entity_id    : entity id for this hosted entity
              remote_entity_id    : entity id for the remote entity
              idp_nameid          : name identifier for the IDP
      
  4. Terminate the link (defederate) between the user's service provider and identity provider accounts using one of the following URLs referencing spMNIRequestInit.jsp.

    • Initiate defederation from the service provider using either HTTP-Redirect binding or SOAP binding respectively:

      http://honey.sun.com:80/opensso/saml2/jsp/spMNIRequestInit.jsp?
      metaAlias=/sp&idpEntityID=maple.sun.com&requestType=Terminate&
      binding=urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect

      http://honey.sun.com:80/opensso/saml2/jsp/spMNIRequestInit.jsp?
      metaAlias=/sp&idpEntityID=maple.sun.com&requestType=Terminate&
      binding=urn:oasis:names:tc:SAML:2.0:bindings:SOAP
    • Initiate defederation from the identity provider using either HTTP-Redirect binding or SOAP binding respectively:

      http://maple.sun.com:80/opensso/saml2/jsp/idpMNIRequestInit.jsp?
      metaAlias=/idp&spEntityID=honey.sun.com&requestType=Terminate&
      binding=urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect

      http://maple.sun.com:80/opensso/saml2/jsp/idpMNIRequestInit.jsp?
      metaAlias=/idp&spEntityID=honey.sun.com&requestType=Terminate&
      binding=urn:oasis:names:tc:SAML:2.0:bindings:SOAP
  5. After defederation, run the previous ldapsearch command again.

    The two properties have no values on both the identity provider and service provider sides.
  6. Federate the user's service provider account and identity provider account again using the URL that references spSSOInit.jsp.

    http://honey.sun.com:80/opensso/saml2/jsp/spSSOInit.jsp?
    metaAlias=/sp&idpEntityID=maple.sun.com
    .
  7. Run the previous ldapsearch command again.
    The two properties have values on both the identity provider and service provider sides again; the value of the name identifier is different from the previous value.
  8. Initiate the creation of a new name identifier using one of the following:

    • Initiate the creation of a new name identifier from the service provider side using spMNIRequestInit.jsp and the following URL:

      http://honey.sun.com:80/opensso/saml2/jsp/spMNIRequestInit.jsp?
      metaAlias=/sp&idpEntityID=maple.sun.com&requestType=NewID&
      binding=urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect
    • Initiate the creation of a new name identifier from the identity provider side using idpMNIRequestInit.jsp and the following URL:

      http://maple.sun.com:80/opensso/saml2/jsp/idpMNIRequestInit.jsp?
      metaAlias=/idp&spEntityID=honey.sun.com&requestType=NewID&
      binding=urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect
  9. Run the previous ldapsearch command for a third time.
    The two properties have values on both the identity provider and service provider sides; the value of the new name identifier is different from both of the previous values.

More information on the JSP can be found in the OpenSSO Enterprise 8.0 Administration Guide.

And, in keeping with the sweet theme of the host machine names, here's The Sweet with Fox on the Run. I still smell hamburgers when I hear this song - high school lunches at the coffee shop with a jukebox.

Friday Jan 09, 2009

SAMLv2 Assertion Failover in OpenSSO

SAMLv2 Assertion Failover, when enabled, redirects a request for an assertion to a second identity provider if the identity provider that initially created the assertion is out of commission. The feature piggybacks on OpenSSO Session Failover configuration by using the same databases. Here is the procedure to configure and test SAMLv2 Assertion Failover.
  1. Deploy 2 instances of OpenSSO Enterprise to act as identity providers and 1 load balancer in front of them.
  2. Set up the entities as a site with servers (using the OpenSSO console) and confirm that the configurations work.
  3. Install and setup session failover as documented in the Sun OpenSSO Enterprise 8.0 Installation and Configuration Guide.
  4. Deploy 1 instance of OpenSSO Enterprise to act as service provider.
  5. On all three provider instances of OpenSSO, enable SAMLv2 Assertion Failover.
    1. Log in to the OpenSSO console as administrator.
    2. Click the Configuration tab.
    3. Click the Global tab.
    4. Click the SAMLv2 Service Configuration link.
    5. Check the box next to Enable SAMLv2 Failover.
    6. Click Save.
    7. Log out of the console.
  6. Configure each server instance of OpenSSO as the appropriate entity provider and member of the same SAMLv2 circle of trust.
  7. Export the entity provider metadata from all three server instances of OpenSSO.
  8. Load the service provider and identity provider metadata on the respective instances of OpenSSO and on the load balancer.

    You need to create the metadata for the load balancer. See your load balancer's documentation for more information. Make sure you change the URL values in the load balancer metadata from the OpenSSO instances behind the load balancer to the load balancer URL itself.
  9. Modify the spAssertionConsumer.jsp on the service provider machine to add sleep that allows enough time to shutdown the identity provider on which the request will land. (See step 11.)

    Object newSession = null;
    SAML2Utils.debug.error("Before sleep Assertion Failover");
    SAML2Utils.debug.message("Before sleep Asserion Failover");
    Thread.sleep(50000);
    SAML2Utils.debug.error("After sleep Assertion Failover");
    SAML2Utils.debug.message("After sleep Asserion Failover");
  10. Initiate single sign-on using the following URL: http://host-machine.domain:port/opensso/saml2/jsp/spSSOInit.jsp?metaAlias=
    /sp&idpEntityID=LB-host-machine.LB-domain

    Before proceeding to the next step, run tail on the SAMLv2 debug logs (located in OpenSSO-install-directory/opensso/debug) on the identity provider host machines to see where the single sign-on request lands.
  11. After providing the service provider user credentials, monitor the log and shutdown the identity provider on which the initial single sign-on request landed.

    Make sure the user is not federated before shutting down the identity provider. The sleep time added to spAssertionConsumer.jsp in the previous step should allow enough time for this. (See step 9.)
  12. Verify that federation successfully occurs after the identity provider is shutdown. This confirms that assertion failover was successful.
  13. Initiate single logout using the following URL:

    http://host-machine.domain:port/opensso/saml2/jsp/spSingleLogoutInit.jsp?metaAlias=
    /sp&idpEntityID=LB-host-machine.LB-domain
  14. Bring the previously shutdown identity provider back up and, once again, initiate single sign-on again using the following URL:

    http://host-machine.domain:port/opensso/saml2/jsp/spSSOInit.jsp?metaAlias=
    /sp&idpEntityID=LB-host-machine.LB-domain
  15. Monitor the log and shutdown the identity provider on which this second single sign-on request landed.
  16. Initiate single logout using the following URL:

    http://host-machine.domain:port/opensso/saml2/jsp/spSingleLogoutInit.jsp?metaAlias=
    /sp&idpEntityID=LB-host-machine.LB-domain
  17. A successful logout confirms assertion failover is working.

And now that Assertion Failover has been correctly configured, put your footsies up and check out this live version of The Killers' latest hit - are we Human or are we dancer?

Tuesday Dec 09, 2008

Integrating OpenSSO and .NET Cheaply and Cheerfully

OpenSSO can be integrated with .NET applications. Here are some ways to achieve single sign-on or attribute sharing:

  1. Install the IIS agent to protect the .NET application, and install OpenSSO as the service provider with the .NET application. The identity provider could then achieve single sign-on with the .NET application, and attributes can be passed down, as part of the HTTP header, to the .NET application.
  2. Securely exchange attributes using the .NET client API provided by OpenSSO for integration with the .NET application. This makes use of the SAMLv2 and the Virtual Federation Proxy feature of OpenSSO.
  3. Deploy Active Directory Federation Services as the service provider with the .NET application. OpenSSO would act as the identity provider. Use the WS-Federation protocol to achieve single sign-on with the .NET application.

While ruminating these options, enjoy Cheap and Cheerful from The Kills EXCELLENT third album Midnight Boom.

Monday Dec 08, 2008

OpenSSO Servers and Sites Configuration with SSL and SSQ

Here is some information regarding how you might configure OpenSSO sites and servers for a sample SAMLv2 deployment. The requirement in this SAMLv2 deployment is to allow normal users to access OpenSSO via pure SSL and administrative users to access OpenSSO via SSL with certificate authentication. The deployment is a straight forward setup (using two instances of OpenSSO and Glassfish, and one load balancer) except for the following:
  1. The requirement for certificate authentication for one group of users and LDAP authentication for t'other group of users.
  2. The users are split into two domains: one for the identity provider and t'other for the service provider. The identity provider will authenticate, and the service provider will control access using a J2EE policy agent.
The load balancer should be configured with two listening sockets but there should be only one configured Site in OpenSSO. The Site configuration does not need to know both listening sockets as long as the two configured listening sockets (in this example, port 1443 and 2443) point to the same instance of OpenSSO. For this deployment do the following configurations.
  • On both instances of OpenSSO, under the Configuration --> Servers and Sites tabs in the console, create one New Server for each OpenSSO instance as in:

    • https://osso1.server.com:1443/opensso
    • https://osso2.server.com:1443/opensso

    Create a New Site with your chosen name and a Primary URL that points to the first virtual IP of the load balancer as in https://lb-vip1.server.com:1443/opensso. Click the created Site and add the second virtual IP of the load balancer, https://lb-vip2.server.com:1443/opensso.

    Click each server previously created to add the created Site as the value of the Parent Site attribute.
  • In the first instance of the Glassfish console, configure two listening sockets:

    • https://osso1.server.com:1443/opensso
    • https://osso1.server.com:2443/opensso

    In the second instance of the Glassfish console, configure two listening sockets:

    • https://osso2.server.com:1443/opensso
    • https://osso2.server.com:2443/opensso
  • In the load balancer, configure two virtual servers that each points to two different pools:

    • Virtual Server 1

      https://lb-vip1.server.com:1443 points to two different pools:

      • https://osso1.server.com:1443/opensso
      • https://osso2.server.com:1443/opensso
    • Virtual Server 2

      https://lb-vip2.server.com:2443 points to two different pools:

      • https://osso1.server.com:2443/opensso
      • https://osso2.server.com:2443/opensso

And from SSL to SSQ, here's Synthecide. Stacey Q was lead singer of this mid-80s Berlin-sounding synth band before she went solo with the Madonna-sounding Two of Hearts. At that point, everyone decided to hate her and she was never heard from again.

Wednesday Nov 26, 2008

Sweeping SAMLv2 Assertions from the 7th Floor

The following information was just put in the Sun OpenSSO Enterprise 8.0 Administration Guide but the new version won't be published until next week. Read the information here first. (There might be some changes to this entry based on answers to questions I have sent the engineer. I will update as necessary.) Requesting Identity Attributes via a SAMLv2 Assertion

The Assertion Query/Request profile specifies a means for requesting attributes (and the corresponding values) from a specific identity profile. A successful response is the return of an assertion containing the requested information. The identity provider acting as the attribute authority uses the com.sun.identity.saml2.plugins.AttributeAuthorityMapper to process queries. This default implementation uses the attribute map table configured in the identity provider's extended metadata; this table maps the requested SAMLv2 attributes to the user profile attributes in the identity data store. (If an attribute map is not configured, no attributes will be returned.)

To set OpenSSO to use a customized attribute mapper implementation, modify the values of the default_attributeAuthorityMapper and the x509Subject_attributeAuthorityMapper properties in the extended metadata of the provider defined as the attribute authority. The default_attributeAuthorityMapper value is used for a standard attribute queries and the x509Subject_attributeAuthorityMapper value is used for attribute queries with an X509 subject. The X509 mapper maps an X509 subject to a user by searching the identity data store for a specified attribute. (The specified attribute is defined as the value of the x509SubjectDataStoreAttrName property in the identity provider extended metadata of the attribute authority.) If the user has the specified attribute and the attribute's value is the same as that of the X509 subject in the attribute query, the user will be used.

Only SOAP binding is supported. Signing is required so make sure the Signing Certificate Alias attribute of the providers acting as the attribute requester and the attribute authority is configured.

  • To send an attribute query from the requester use the method of com.sun.identity.saml2.profile.AttributeQueryUtil.

    public static Response sendAttributeQuery(
    AttributeQuery attrQuery,
    String attrAuthorityEntityID,
    String realm,
    String attrQueryProfile,
    String attrProfile, String binding)
    throws SAML2Exception;
  • To construct an AttributeQuery object, use com.sun.identity.saml2.assertion.\* and com.sun.identity.saml2.protocol.\*.

Requesting a Cached SAMLv2 Assertion

The Assertion Query/Request profile specifies a means for requesting existing assertions using a unique identifier. The requester initiates the profile by sending an assertion request, referenced by the identifier, to a SAMLv2 authority. The SAMLv2 authority processes the request, checks the assertion cache for the identifier, and issues a response to the requester.

NOTE - In the metadata file of the identity provider acting as the SAMLv2 authority, add the following attribute to enable it to store assertions generated in the single sign-on, authentication query or attribute query process.

<IDPSSOConfig metaAlias="/idp">
<Attribute name="assertionCacheEnabled">
<Value>true</Value>
</Attribute>
</IDPSSOConfig>

com.sun.identity.saml2.plugins.AssertionIDRequestMapper is the default implementation used to process the assertion request. To define a customized mapper, change the value of the assertionIDRequestMapper property in the extended metadata of the provider acting as SAMLv2 attribute authority or authentication authority.

  • To send a request for an assertion from a provider use either of the methods of com.sun.identity.saml2.profile.AssertionIDRequestUtil as below.
    public static Response sendAssertionIDRequest(
    AssertionIDRequest assertionIDRequest,
    String samlAuthorityEntityID,
    String role,
    String realm,
    String binding)
    throws SAML2Exception;
    public static Assertion sendAssertionIDRequestURI(
    String assertionID,
    String samlAuthorityEntityID,
    String role,
    String realm)
    throws SAML2Exception;
  • To construct an assertion request object, use com.sun.identity.saml2.assertion.\* and com.sun.identity.saml2.protocol.\* .

If SOAP binding is used, signing is required so the Signing Certificate Alias attribute of the service provider, identity provider, attribute authority and authentication authority metadata must be configured. In order to implement URI binding, you must write a custom mapper so that authenticateRequesterURI will not throw an exception.

Requesting SAMLv2 Authentication Context Information

A SAMLv2 assertion contains information regarding the context of a principal's authentication. The requesting party may require this additional information (for example, the authenticating technology or protocol used) in order to assess the level of confidence they can place in the assertion. To retrieve authentication context information, the service provider issues a query to the authentication authority.

Only SOAP binding is supported for this request And signing is required so make sure the Signing Certificate Alias attribute of the service provider and the authentication authority is configured.

To Configure for Authentication Context Query
  1. Create and load the metadata for the service provider.
  2. Create the metadata for the identity provider using ssoadm and specifying the following additional options.
    • -C Defines the meta Alias for the hosted authentication authority to be created. The format must be realm name/identifier.
    • -D Defines the authentication authority signing certificate alias.
    • -E Defines the authentication authority encryption certificate alias.

    For example:
    ssoadm create-metadata-templ -u amadmin -f /tmp/pw -m /home/user1/tmp/mm -x /home/usr1/tmp/xx -s /idp -a test -r test -C /authna -D test2 -E test2 -y example.com
  3. Add the following attribute to the identity provider metadata file just created. This allows the identity provider to store assertions generated during the SAMLv2 single sign-on process.
    <IDPSSOConfig metaAlias="/idp">
    <Attribute name="assertionCacheEnabled">
    <Value>true</Value>
    </Attribute>
    </IDPSSOConfig>
  4. Configure for SAMLv2 single sign-on.
  5. Do either of the following:
    • To send an authentication query from the service provider use the com.sun.identity.saml2.profile.AuthnQueryUtil method.
      public static Response sendAuthnQuery( AuthnQuery authnQuery, String authnAuthorityEntityID, String realm, String binding) throws SAML2Exception;
    • To construct an AuthnQuery object, use com.sun.identity.saml2.assertion.\* and com.sun.identity.saml2.protocol.\*.

Mapping SAMLv2 Name Identifiers

The NameID Mapping Protocol allows a service provider that shares an identifier for a principal with an identity provider to obtain a name identifier for said principal in another format or that is in another federation name space (for example, is shared between the identity provider and another service provider). The requester initiates the profile by sending a NameIDMappingRequest message to the identity provider. After processing the request, the identity provider issues a NameIdMappingResponse message to the requester.

Only SOAP binding is supported. Signing is required so make sure the Signing Certificate Alias attribute of the identity provider and the service provider is configured.

To send a NameIDMappingRequest message from the service provider, use the method of the com.sun.identity.saml2.profile.NameIDMapping.

public static NameIDMappingResponse initiateNameIDMappingRequest( Object session,
String realm,
String spEntityID,
String idpEntityID,
String targetSPEntityID,
String targetNameIDFormat,
Map paramsMap) throws SAML2Exception;

And now that we are finished sweeping the floor, how about some dancing on the floor? Here's a home-made video to Paul Nicholas' number 7 hit from 1977, Heaven on the 7th Floor.

Friday Oct 31, 2008

Test the OpenSSO Deployment Documents

I know there are people out there who have been wondering where my blog entries have been for the last two and a half months - and to both of you I say: I've been assiduously (thanks for the word, Alan) working on two deployment books for release with Sun OpenSSO Enterprise 8.0. Here are links to the PDFs - test them out and let me know what you think. But all that work has made me drowsy so I'm taking two weeks off now. In the meantime, enjoy As We Stumble Along featuring Robert Martin as Man in Chair and Beth Leavel as The Drowsy Chaperone. You gotta love a song that rhymes stumble with...parumble?

Thursday Apr 03, 2008

Reviewing Implementing Federation and Watching I'm Gonna Be Strong

Between blog entries, I am writing the Sun Java System Federated Access Manager 8.0 Technical Overview. Aside from writing about new features, this book also includes updated material first written for Access Manager 7.1, the SAMLv2 Plugin for Federation Services and Federation Manager 7.0. Towards that lofty goal, I have finished a draft for the chapter entitled Implementing Federation. This chapter collects information regarding the federation protocol available in Federated Access Manager 8.0.

I've sent the chapter to internal Sun engineers for review but I also want to hear from the OpenSSO community. A PDF of this chapter is available for your perusal here. If you have any ideas on what might be missing, or comments on what is currently included please feel free to leave a comment or email me.

Since I'm gonna be strong when I read all these comments, here's Gene Pitney singing I'm Gonna Be Strong. This man has one of the best voices; I never tire of hearing the old records (yes, records) that I have of his.

Cyndi Lauper, one of the best female voices, covered I'm Gonna Be Strong when she was the lead singer of Blue Angel in 1980 (and then again on a solo album). Here's a clip of Cyndi singing the Barry Mann and Cynthia Weil classic with Blue Angel.

I also covered I'm Gonna Be Strong (a cappella, mind you) when I was performing songs and pithy comedy eons ago. I shall find that video tape and one day make this couplet a triplet. That should be scary!

Wednesday Mar 12, 2008

Developers Call to Federation/Web Services/SAML Arms

This is a link to a PDF of the Federation, SAMLv2, and Web Services chapters of the FAM8 Developers Guide. This is a skeleton of what is going in the book. Let me know if you see something (or know of something) that I missed.

And here's another type of arms that belongs to someone with whom Elvis Presley wants to lie.

Loving Arms has been covered by many artists since it's original recording in the 60s. My favorite versions are Elvis's, the Dixie Chicks, and Ms. Millie Jackson. What's yours?
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