In the previous articles in this series I was discussing what should be known to get started with OSP and started reading through the osp.log of a server starting up. It is interesting to see all that goes on under the covers to get a good feel for what is going right. When something goes wrong, potentially this could help you figure out if something that should have happened, failed to happen, without logging it. Or at least that is my theory. Should this actually work and help you out, please comment and let me know.

[OIDP]
Time: 2015-12-15T17:02:38.219-0500
Level: TRACE
Java Execution:
 Class: com.novell.identity.common.ldap.jndi.A
 Method: A
 Line Number: -1
 Thread: localhost-startStop-1
Message: Initialized Connection Pool: Id: PL4fa6d730-c558-4631-9888-a7bd29076270:0a8fb59f-27ff-4c7e-8dc9-fabf6c38b8b5
    UserStore: IDM eDir
    Replica Host: ldaps://10.1.1.42
    Pool Open?: false
    Max Connections: 31
    User Name: cn=admin,o=acme

[OIDP]
Time: 2015-12-15T17:02:38.227-0500
Level: TRACE
Java Execution:
 Class: com.novell.identity.common.ldap.jndi.A
 Method: G
 Line Number: -1
 Thread: localhost-startStop-1
Message: Pool Id: PL4fa6d730-c558-4631-9888-a7bd29076270:0a8fb59f-27ff-4c7e-8dc9-fabf6c38b8b5, Opening pool on host: ldaps://10.1.1.42


[OIDP]
Time: 2015-12-15T17:02:38.261-0500
Level: TRACE
Java Execution:
 Class: com.novell.identity.common.ldap.jndi.JNDIConnection
 Method: <init>
 Line Number: -1
 Thread: localhost-startStop-1
Message: Connection: 48238c0e-b6e7-47b2-bc27-7c9263cdb79e, Environment Parameters for InitialDirContext() method call:
Key: java.naming.factory.initial, Value: com.sun.jndi.ldap.LdapCtxFactory
Key: java.naming.provider.url, Value: ldaps://10.1.1.42:636
Key: com.sun.jndi.ldap.connect.timeout, Value: 0
Key: java.naming.security.principal, Value: cn=admin,o=acme
Key: java.naming.security.authentication, Value: simple
Key: java.naming.security.credentials, Value: *****
Key: java.naming.security.protocol, Value: ssl
Key: java.naming.ldap.factory.socket, Value: com.novell.osp.util.net.client.OSP_SSLSocketFactory


[OIDP]
Time: 2015-12-15T17:02:38.263-0500
Level: ALL
Java Execution:
 Class: com.novell.identity.common.ldap.jndi.JNDIConnection
 Method: <init>
 Line Number: -1
 Thread: localhost-startStop-1
Message: JNDI Debug Event:
Create Connection: cId: 48238c0e-b6e7-47b2-bc27-7c9263cdb79e, usId: idm_idv, rId: 0a8fb59f-27ff-4c7e-8dc9-fabf6c38b8b5, U: cn=admin,o=acme, T: 1

Next up we see the LDAP connection being built. Note it is using a pool of connections. This is because OSP is a much more full featured product than we get to see in IDM. The real full version of this is used in the xAccess product line (Social Access, Mobile Access, Cloud Access) as a lightweight, SAML federation only NAM stand in.

We get a tightly configured, limited version for IDM's use.

One nice thing is that we get to see the Java parameters in use for the connection. This is helpful, since sometimes you need to tune things, and we can see if they are set or not. I wonder if it would be possible to pass in to the start script for Tomcat that is loading OSP, a Java parameter in case we needed to change one of these or perhaps add some tuning value.

[OSP]
Time: 2015-12-15T17:02:38.389-0500
Level: TRACE
Java Execution:
 Class: com.novell.oidp.configuration.ConfigurationManager
 Method: H
 Line Number: -1
 Thread: localhost-startStop-1
Message: Loading Data Sources:
    Loading Data Source: com.novell.oidp.source.ldap.LDAPSource
      Display Name: IDM eDir
      Id: idm_idv
      Load Successful!
    Loading Data Source: com.novell.oidp.source.file.FileSource
      Display Name: Users From File
      Id: firstFile
      Load Successful!

Here again we see that OSP is more powerful than we get to see. It supports a User file for logins, as well as eDirectory and SAML. It would be nice to know what the file it is looking at should contain, and where it should be stored, as it would be a nice workaround when LDAP is broken, to perhaps allow a direct login to try and fix it. Of course if it ships with a static username and password buried in there somewhere that would be a bad security hole. But I have seen no evidence of that ever. As a way to get in to fix things, it might be a nice backup t have handy.

Regardless, we see that it has two data sources configured in this stripped down implementation. The LDAP source and the file source.

[OIDP]
Time: 2015-12-15T17:02:38.424-0500
Level: TRACE
Java Execution:
 Class: com.novell.oidp.source.ldap.LDAPAuthenticationSource
 Method: <init>
 Line Number: -1
 Thread: localhost-startStop-1
Message: LDAPAuthenticationSource configuration:
 Display Name: Authentication from IDM eDir
 Id: bisadus
 Data Source Ref Id: idm_idv Trust Source Ref Id: theLdapUserTS Restrict to contexts: false
 <Context(uri.oidp.xml.config.01.2011)>:
  Context: ou=Active,ou=People,o=acme
  Order: 0
  Scope: 2
  Decorator: search

 <Context(uri.oidp.xml.config.01.2011)>:
  Context: ou=ServiceAccounts,o=acme
  Order: 1
  Scope: 2
  Decorator: search

Here we see it defining the data source a bit more. I think we are seeing multiple classes calling up and down the stack and tracing out with extra information, so it looks a bit repetitive but is really just reporting at different levels.

We also can see that there are two scoped containers, the user container and an administrative user container. There is an ordering, so it checks for users first. This actually answers a question I wondered about elsewhere, about a case I ran into at a client, where uaadmin was actually in the Users container, and there was another instance in the admins container. Which one would it use to login with first. Based on this, I would guess the Users located account since that is the first in the search order.

Then we see an attribute mapping, that is a bit verbose, but since there is no configuration for this and no documentation of what is actually mapped, it is worth posting the whole thing to get it on the record.

 <AttributeMapping(uri.oidp.xml.config.01.2011)>:

  <AttributeMapEntry(uri.oidp.xml.config.01.2011)>:
   Local Name: userDN
   Native Name: {$dn}
   In Encoding: None
   Out Encoding: None
   Character Set for Encoding: UTF-8
   Is it a Login Name: false
   Is it a Login Password: false
   Is it Cacheable: true

  <AttributeMapEntry(uri.oidp.xml.config.01.2011)>:
   Local Name: userCN
   Native Name: cn
   In Encoding: None
   Out Encoding: None
   Character Set for Encoding: UTF-8
   Is it a Login Name: false
   Is it a Login Password: false
   Is it Cacheable: true

  <AttributeMapEntry(uri.oidp.xml.config.01.2011)>:
   Local Name: Surname
   Native Name: sn
   In Encoding: None
   Out Encoding: None
   Character Set for Encoding: UTF-8
   Is it a Login Name: false
   Is it a Login Password: false
   Is it Cacheable: true

  <AttributeMapEntry(uri.oidp.xml.config.01.2011)>:
   Local Name: givenName
   Native Name: givenName
   In Encoding: None
   Out Encoding: None
   Character Set for Encoding: UTF-8
   Is it a Login Name: false
   Is it a Login Password: false
   Is it Cacheable: true

  <AttributeMapEntry(uri.oidp.xml.config.01.2011)>:
   Local Name: mail
   Native Name: mail
   In Encoding: None
   Out Encoding: None
   Character Set for Encoding: UTF-8
   Is it a Login Name: false
   Is it a Login Password: false
   Is it Cacheable: true

  <AttributeMapEntry(uri.oidp.xml.config.01.2011)>:
   Local Name: saml2-mapping-attr
   Native Name: cn
   In Encoding: None
   Out Encoding: None
   Character Set for Encoding: UTF-8
   Is it a Login Name: false
   Is it a Login Password: false
   Is it Cacheable: true

  <AttributeMapEntry(uri.oidp.xml.config.01.2011)>:
   Local Name: initials
   Native Name: initials
   In Encoding: None
   Out Encoding: None
   Character Set for Encoding: UTF-8
   Is it a Login Name: false
   Is it a Login Password: false
   Is it Cacheable: true

  <AttributeMapEntry(uri.oidp.xml.config.01.2011)>:
   Local Name: nrfMemberOf
   Native Name: nrfMemberOf
   In Encoding: None
   Out Encoding: None
   Character Set for Encoding: UTF-8
   Is it a Login Name: false
   Is it a Login Password: false
   Is it Cacheable: false

  <AttributeMapEntry(uri.oidp.xml.config.01.2011)>:
   Local Name: srvprvPreferredLocale
   Native Name: srvprvPreferredLocale
   In Encoding: None
   Out Encoding: None
   Character Set for Encoding: UTF-8
   Is it a Login Name: false
   Is it a Login Password: false
   Is it Cacheable: true

Here we see the attributes that are requested and stored about a user in each session. Compiling that list of attributes into a simple list I see:

	userDN
	userCN
	Surname
	Given Name
	mail
	saml2-mapping-attr (aka cn)
	initials
	nrfMemberOf
	srvprvPreferredLocale

Of that list, only saml2-mapping-attr is configurable. When you configure SAML in OSP you specify two values. The URL of the metadata to consume for federation and the mapping attribute. The metatdata URL must be an HTTP resource, since I could not figure out the syntax to specify a file path. However it does not have to be on the actual IDP, it can be hosted anywhere, so long as it is retrievable by OSP. In fact I found when trying to get Shibboleth working I needed to edit the metadata just for this connection, so I grabbed the XML file from the IDP, edited and modified it, and then hosted it on a Tomcat server elsewhere for OSP to go get it. Alas, once day they rebuilt that server and forgot why this very odd file was being hosted there and all of IDM web apps failed, but that was just a communication issue. People communication, not network communication in this case.

The SAML mapping attribute is basically what the IDP needs to send back, after a successful authentication to OSP, so OSP can then lookup the user in LDAP. You can see it wants more info from LDAP than just the username, it wants enough to be able to show basic information about the user without further lookups being required. Though why initials is in that list is beyond me.

[OIDP]
Time: 2015-12-15T17:02:38.493-0500
Level: TRACE
Java Execution:
 Class: com.novell.oidp.configuration.ConfigurationManager
 Method: A
 Line Number: -1
 Thread: localhost-startStop-1
Message: Loading Attribute Maps:
 Map Count: 1
 Map: Name: SAML2 Attribute Map, Id: saml2-attr-map
 Map Entry Count: 1
  Entry: Local: saml2-mapping-attr, Saml: cn

Here we note it calls out the saml2 mapping attribute as cn. Of course, you could use anything, like workforceID if your IDP returned an employee number, or email address or the like.

[OIDP]
Time: 2015-12-15T17:02:38.754-0500
Level: TRACE
Java Execution:
 Class: com.novell.oidp.configuration.ConfiguratorBase
 Method: loadTrustedIDPs
 Line Number: -1
 Thread: localhost-startStop-1
Message: Loading Trusted IDP:

   <TrustedIDP(uri.oidp.xml.config.01.2011)>:

    Id: saml2-idp
    Display Name: SAML2 Identity Provider
    Enabled: true
    Validate Metadata Cert: false

    <Metadata(uri.oidp.xml.config.01.2011)>:

     Source: https://www.acme.com/nidp/saml2/metadata

    <AccessSettings(uri.oidp.xml.config.01.2011)>:

     Auto Intro: false
     Force Auth At IDP: false
     Create Federation At Login: false
     Advertise on Federation Mgmt Dialog: true
     Proxy Count: -1
     Requested Context Type: 0
     Provide Discovery Service: true
     Attr Map Fail Option: DO_NOTHING
     SOAP Security Method: 0
     Encrypt Name Ids: false
     Encrypt Assertions: false
     Authentication response Proto Binding: urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST
     Proxy Requests from SPs: true
     Prompt for Password on Match: false
     User Lookup Ref Id: saml2-user-lookup
     Attribute Map Ref Id: saml2-attr-map

     <UserResolution(uri.oidp.xml.config.01.2011)>:
      Id Method: map

      <AttributeMapEntry(uri.oidp.xml.config.01.2011)>:
       Attribute Id: saml2-mapping-attr

     <AuthenticationSourceList(uri.oidp.xml.config.01.2011)>:

      <AuthenticationSourceReference(uri.oidp.xml.config.01.2011)>:
       Id: one
       Ref Id: bisadus

     <AttributeMapEntry(uri.oidp.xml.config.01.2011)>:
      Attribute Id: saml2-mapping-attr
      Decorator: miscellaneous

     <AuthCards(uri.oidp.xml.config.01.2011)>:

      <AuthCard(uri.oidp.xml.config.01.2011)>:
       Id: saml2-auth-card
       Endpoint Url: null
       Endpoint Type(s): 
       UserAgent Type(s): browser
       Group Ref Id: null
       Show: true
       Authentication Required: true

       <ImageSetList(uri.oidp.xml.config.01.2011)>:

        <ImageSetReference(uri.oidp.xml.config.01.2011)>:
         Ref Id: ospImageRef

In this snippet we start making the SAML federation connection. I wanted to show that entire block in its entirety so you would understand the shape of the log when looking for it. I find it useful to recognize the shape of parts of trace. For example while reading DStrace for a driver, there are 'shapes' in the text, that allow you to page past them very fast, without reading anything but recognizing the shape to ignore or stop and read. Try it one day. The heartbeat query has a small XML snippet and no rules seem to execute. This looks like a different shape than when a modify or add comes through. You will be surprised how much faster you can find things in trace using this approach.

    Id: saml2-idp
    Display Name: SAML2 Identity Provider
    Enabled: true
    Validate Metadata Cert: false

    <Metadata(uri.oidp.xml.config.01.2011)>:

     Source: https://www.acme.com/nidp/saml2/metadata

Here we see that SAML is enabled, we do not validate the metadata certificate, which is interesting, and we report the URL of the metadata file. I like to remind everyone using OSP that each keystore (OSP, Tomcat, and cacerts for the Java in use) should have all the public keys of all the various certs in use. It just simplifies things since exactly what is needed where is unclear, and it is much simpler to just add them where needed.

Some are obvious. OSP runs as a web application and uses its own keystore, so it needs to have its own private key and the public key to trust Tomcat that runs the web applications. It also talks to eDirectory so the tree CA is needed to be trusted as well. If SAML is being used the certificate in the metadata needs to be trusted as well.

I just find it simpler to get the public keys (including intermediate certificates if in use by the signer) for:

OSP private key
Tomcat private key
eDirectory Certificate Authority
IDP metadata

Then I import them into the keystore OSP uses, Tomcat uses, cacerts for the Identity Apps, and then into the IDP's keystore.

Personally I prefer to use one keystore for Tomcat and OSP which saves me a few steps, but that is not required. Using two or one keystores is supported.

Next we get to see some of the settings OSP is using. Presumably these are set somewhere, buried in the JAR and if you really needed to, you could probably expand the WAR, find the file, edit it and repack the WAR. Someone suggested the specific location to do this as a comment on my OSP and Shibboleth series, since we had to change something on the Shibboleth end to conform to how OSP works. The other approach would be to try and change OSP to conform to how Shibboleth works. As always, that likely causes support issues, mostly because you would have to redo this step on every patch, but it is good to know it is a possible option.

Auto Intro: false
Force Auth At IDP: false
Create Federation At Login: false
Advertise on Federation Mgmt Dialog: true
Proxy Count: -1
Requested Context Type: 0
Provide Discovery Service: true
Attr Map Fail Option: DO_NOTHING
SOAP Security Method: 0
Encrypt Name Ids: false
Encrypt Assertions: false
Authentication response Proto Binding: urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST
Proxy Requests from SPs: true
Prompt for Password on Match: false
User Lookup Ref Id: saml2-user-lookup
Attribute Map Ref Id: saml2-attr-map

I believe the issue I had to turn off on Shibboleth was the Encrypt Assertions, so that might have been helpful to know back then. The rest are not clear if we should ever care or matter, but good to know they are options that are potentially tweakable. This again reminds us that OSP is more than what we see, when given away with IDM.

[OIDP]
Time: 2015-12-15T17:02:38.754-0500
Level: TRACE
Java Execution:
 Class: com.novell.oidp.saml2.SAML2Protocol
 Method: loadTrustedProvider
 Line Number: -1
 Thread: localhost-startStop-1
Message: Loading SAML2 Trusted Provider: saml2-idp, isIDP: true, validateMetadataCert: false

Starting up the SAML provider.

[OIDP]
Time: 2015-12-15T17:02:38.754-0500
Level: TRACE
Java Execution:
 Class: com.novell.oidp.protocol.TrustedProviderProtocol
 Method: getMetadata
 Line Number: -1
 Thread: localhost-startStop-1
Message: Requesting metadata for SAML2 Identity Provider from https://www.acme.com/nidp/saml2/metadata

Getting the metadata is key for getting SAML to work. If there is an error here, nothing else is going to work. Confirm the URL is correct, and use something like 'wget' to test that the firewall entries allow connectivity. We had an issue where the metadata just could not be read from the IDP itself. We were able to get to it from another device, save the XML and host it on another server that OSP could read. That was perfectly fine, since all that matters is that it can be read. I wish there was a supported syntax to read it from a file that would be useful for such a case.

The major downside to using a third server is, some day down the road, some admin might say, why are we offering this odd XML page, and remove it. Or perhaps they might do an upgrade and forget to copy this file back in. Suddenly your OSP and IDM Web Apps stop working. But that would never happen, right? Except for all the times it does.

[OIDP]
Time: 2015-12-15T17:02:39.091-0500
Level: TRACE
Java Execution:
 Class: com.novell.oidp.configuration.ConfiguratorBase
 Method: getAttrSettings
 Line Number: -1
 Thread: localhost-startStop-1
Message: Resolution of Assertion Attribute Map with refId "saml2-attr-map" resulted in com.novell.oidp.attributes.assertion.AssertionAttributeMap@11553185

This seems to get the attribute it is looking for, into the proper Java object that is needed.

[OIDP]
Time: 2015-12-15T17:02:39.110-0500
Level: TRACE
Java Execution:
 Class: com.novell.oidp.saml2.authority.xml.ConfiguratorSaml2
 Method: configure
 Line Number: -1
 Thread: localhost-startStop-1
Message: SAML2 Entity Descriptor:

   <md:EntityDescriptor(urn:oasis:names:tc:SAML:2.0:metadata)>:
    Provider Id: null
    Succinct Id: null
    Id: id4BoCI-BAKLfPGe2fI-7IZDFbXK0
    Cache Duration: null
    Valid Until: 0
    Entity Id: https://www.acme.com/osp/a/idm/auth/saml2/metadata

    <md:Organization(urn:oasis:names:tc:SAML:2.0:metadata)>:
     Organization Names Count: 1
      en, NetIQ
     Organization Display Names Count: 1
      en, NetIQ Corporation
     Organization Url Count: 1
      en, http://www.netiq.com


    <md:ContactPerson(urn:oasis:names:tc:SAML:2.0:metadata)>:
     Contact Type: technical
     Company: NetIQ Corporation
     Given Name: NetIQ
     Surname: other
     Email Address Count: 1
      Email Address: support@netiq.com
     Phine Number Count: 1
      Phone Number: 1-801-861-4000


    <md:SPSSODescriptor(urn:oasis:names:tc:SAML:2.0:metadata)>:
     Provider Id: https://www.acme.com/osp/a/idm/auth/saml2/metadata
     Succinct Id: ac9a4951449a7b185502df89d1726ba5fd30c0ff
     Id: idQHRLv861t3JiNlJa8-qihCE4K9E
     Cache Duration: null
     Valid Until: 0
     Base Url: https://www.acme.com/osp/a/idm/auth/saml2/
     Key Descriptor Count: 2
      Key Size: , -1
      Key Size: , -1
     Protocol Support Enumeration Count: 1
      Enum: , urn:oasis:names:tc:SAML:2.0:protocol
     Intro Url: null
     Is IDP: false
     Single Sign On Services Count: 2
      urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST
        <md:SingleSignOnService(urn:oasis:names:tc:SAML:2.0:metadata)>:
         Binding: urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST
         Location: https://www.acme.com/osp/a/idm/auth/saml2/spsso
      urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect
        <md:SingleSignOnService(urn:oasis:names:tc:SAML:2.0:metadata)>:
         Binding: urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect
         Location: https://www.acme.com/osp/a/idm/auth/saml2/spsso
     Artifact Resolution Services Count: 0
     Single Logout Services Count: 1
      urn:oasis:names:tc:SAML:2.0:bindings:SOAP
        <md:SingleLogoutService(urn:oasis:names:tc:SAML:2.0:metadata)>:
         Binding: urn:oasis:names:tc:SAML:2.0:bindings:SOAP
         Location: https://www.acme.com/osp/a/idm/auth/saml2/spsoap
     Manage Name Id Services Count: 0
     Name Id Formats Count: 2
      Format: urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
      Format: urn:oasis:names:tc:SAML:2.0:nameid-format:transient
     Want Authn Requests Signed: false
     Want Assertions Requests Signed: false
     Assertion Consumer Service Count: 2
      urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST, 
<md:AssertionConsumerService(urn:oasis:names:tc:SAML:2.0:metadata)>:
 Binding: urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST
 Location: https://www.acme.com/osp/a/idm/auth/saml2/spassertion_consumer
 Index: 0
 Is Default: true

      urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect, 
<md:AssertionConsumerService(urn:oasis:names:tc:SAML:2.0:metadata)>:
 Binding: urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect
 Location: https://www.acme.com/osp/a/idm/auth/saml2/spassertion_consumer
 Index: 1
 Is Default: false

     Attribute Consuming Service Count: 0

Here we parse our metadata file and start using it. Let us see what is interesting in there, I think seeing it as a whole is helpful first, then dissect it into pieces to better understand it.

   <md:EntityDescriptor(urn:oasis:names:tc:SAML:2.0:metadata)>:
    Provider Id: null
    Succinct Id: null
    Id: id4BoCI-BAKLfPGe2fI-7IZDFbXK0
    Cache Duration: null
    Valid Until: 0
    Entity Id: https://www.acme.com/osp/a/idm/auth/saml2/metadata

This Entity Id initially confused me. The URL to get the OSP metadata, has an end node of spmetadata instead of metadata, and I thought we had the URL wrong, but one is a real URL to retrieve the data, and the other value is just a unique value. Each Entity ID in a system should be unique. However since SAML is vaguely intended as a global system tieing systems together, it makes sense to have a gloally unique value. Using a resolvable URL would be one way of making sure it is not going to collide.

    <md:Organization(urn:oasis:names:tc:SAML:2.0:metadata)>:
     Organization Names Count: 1
      en, NetIQ
     Organization Display Names Count: 1
      en, NetIQ Corporation
     Organization Url Count: 1
      en, http://www.netiq.com

Advertising. It is everywhere, you cannot get away from it. Or converesly, it tells you the kind of IDP you are talking to and is helpful to know. I think it is just advertising. Even if no one ever sees it.

    <md:ContactPerson(urn:oasis:names:tc:SAML:2.0:metadata)>:
     Contact Type: technical
     Company: NetIQ Corporation
     Given Name: NetIQ
     Surname: other
     Email Address Count: 1
      Email Address: support@netiq.com
     Phine Number Count: 1
      Phone Number: 1-801-861-4000

Ok, maybe it is not purely to advertise. It does make sense to report the vendor of an IDP and even a contact number for when issues arise. Of course a Phine number is less helpful than a phone number I assume. A funny typo.

    <md:SPSSODescriptor(urn:oasis:names:tc:SAML:2.0:metadata)>:
     Provider Id: https://www.acme.com/osp/a/idm/auth/saml2/metadata
     Succinct Id: ac9a4951449a7b185502df89d1726ba5fd30c0ff
     Id: idQHRLv861t3JiNlJa8-qihCE4K9E
     Cache Duration: null
     Valid Until: 0
     Base Url: https://www.acme.com/osp/a/idm/auth/saml2/
     Key Descriptor Count: 2
      Key Size: , -1
      Key Size: , -1
     Protocol Support Enumeration Count: 1
      Enum: , urn:oasis:names:tc:SAML:2.0:protocol
     Intro Url: null
     Is IDP: false
     Single Sign On Services Count: 2
      urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST
        <md:SingleSignOnService(urn:oasis:names:tc:SAML:2.0:metadata)>:
         Binding: urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST
         Location: https://www.acme.com/osp/a/idm/auth/saml2/spsso
      urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect
        <md:SingleSignOnService(urn:oasis:names:tc:SAML:2.0:metadata)>:
         Binding: urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect
         Location: https://www.acme.com/osp/a/idm/auth/saml2/spsso
     Artifact Resolution Services Count: 0
     Single Logout Services Count: 1
      urn:oasis:names:tc:SAML:2.0:bindings:SOAP
        <md:SingleLogoutService(urn:oasis:names:tc:SAML:2.0:metadata)>:
         Binding: urn:oasis:names:tc:SAML:2.0:bindings:SOAP
         Location: https://www.acme.com/osp/a/idm/auth/saml2/spsoap
     Manage Name Id Services Count: 0
     Name Id Formats Count: 2
      Format: urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
      Format: urn:oasis:names:tc:SAML:2.0:nameid-format:transient
     Want Authn Requests Signed: false
     Want Assertions Requests Signed: false
     Assertion Consumer Service Count: 2
      urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST, 
<md:AssertionConsumerService(urn:oasis:names:tc:SAML:2.0:metadata)>:
 Binding: urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST
 Location: https://www.acme.com/osp/a/idm/auth/saml2/spassertion_consumer
 Index: 0
 Is Default: true

      urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect, 
<md:AssertionConsumerService(urn:oasis:names:tc:SAML:2.0:metadata)>:
 Binding: urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect
 Location: https://www.acme.com/osp/a/idm/auth/saml2/spassertion_consumer
 Index: 1
 Is Default: false

     Attribute Consuming Service Count: 0

I think someone who is familiar with SAML could have a fun time explaining what is going on in there. That would not be me. For me the key takeaways is that there are at least two advertised services, from OSP, for HTTP-POST, HTTP-REDIRECT, and SOAP.

Interestingly, NAM offers all these services when acting as an IDP, but uses the same URL for all of them. You can see that OSP uses a different URL for each. Shibboleth is the same and uses different URL's for all three as well.

This was an issue in earlier versions of OSP where it would parse the metadata from the OSP and use the wrong entry. I was able to find (with a colleagues help) the actual POST data in the logs of a session and use an HTTP tool, POST it and it worked. But the OSP login failed. This showed us, it was POSTing the data to the wrong URL. For us the fix was easy, edit the metadata and swap the URLs. This has since been fixed in the OSP 5.x version line and higher.

[OSP]
Time: 2015-12-15T17:02:39.132-0500
Level: TRACE
Java Execution:
 Class: com.novell.osp.OSPTenant
 Method: start
 Line Number: -1
 Thread: localhost-startStop-1
Message: Tenant idm started!

Finally the tenant is up and running. That was not so bad, right?

I will probably keep trying to find interestin snippets of osp.log to discuss, since it is basically completely undocumented by NetIQ. If you have an interesting snippet, please post with your thoughts, best way to learn is to share!