Getting Started with OSP – Part 5

0 Likes
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!

Labels:

How To-Best Practice
Comment List
Related
Recommended