Shibb + Panopto + AD TokenGroups

[Chuck Kimber]

We're working on implementing Panopto to record courses and hoping we
can pull off authentication with Shibboleth. Out of the box Panopto
supports ADFS, which is SAML 2, of course. Panopto doesn't officially
support anything except ADFS, but we'd like to avoid confusing users
by shipping them to yet another SSO.

So my first question would be, has anyone out there successfully used
Shibboleth to authenticate Panopto? The google searches and reading
I've done seem thin... If someone has pulled it off, they don't seem
to be talking about it. I would welcome any tips, examples, insight
and warnings you might have.

I have been experimenting and playing with it, based on their ADFS
config (http://support.panopto.com/focus-4-articles/24-activedirectory/399-hosted-panopto-federated-authentication)
and have stored their metadata, configured basic filters etc, but
there is one AD attribute they want that seems problematic. The AD
attribute "tokenGroups". I am unable to pull this attribute
successfully with any tool, even powershell with the ActiveDirectory
module, to examine it.
http://msdn.microsoft.com/en-us/library/windows/desktop/ms680275%28v=vs.85%29.aspx
From what I've uncovered so far this attribute seems to be some kind
of conglomerate value that has to then be broken down into SID's and
enumerated. Even if I can get my hands on that attribute, I'm not
sure how I would pull off the enumeration of it in Shibboleth. I'm
hoping someone out there has cracked this nut before and can show me
how. Any ideas?

Chuck
Utah State University
--
To unsubscribe from this list send an email to users-un...@shibboleth.net

[Schumacher, Adam J.]

tokenGroups is not an attribute that is stored on any domain controllers. It is computed at the client in the Microsoft security api DLLs. You could duplicate this functionality on the IDP by querying the memberOf attribute, programmatically retrieving all nested groups (making sure there are no nesting loops of course), converting the DNs of those groups to their SIDs and then combining those SIDs into the single attribute.

There is a Microsoft KB article that sort of describes this that might help you: http://support.microsoft.com/kb/301916

And this one is more programmatic that describes how the data structure is constructed: http://msdn.microsoft.com/en-us/library/windows/desktop/aa379624(v=vs.85).aspx

Adam Schumacher
Information Security Engineer
Creighton University

> unsub...@shibboleth.net

[Randy Wiemer]

> Out of the box Panopto supports ADFS, which is SAML 2,>
 

The statment that ADFS is SAML 2 is not really relevant in this case.
 
The metadata they publish reveals they are using WS-* protocols and not SAML.  Their application is probably using WIF which means they don't really even need ADFS on their side.
 
https://panoptoacs.accesscontrol.windows.net/FederationMetadata/2007-06/FederationMetadata.xml 
 
You can use an ADFSv2 server on your side to perform what amounts to a protocol translation from the SAMLv2 performed by your Shibboleth IdP to WS-Federation that the service provider expects.  Your users would not have to see any of this if you control the URLs they'd use to reach the service provider.

Randy
Oxford Computer Group
 

> From: chuck....@usu.edu
> Date: Tue, 20 Mar 2012 15:04:06 -0600
> Subject: Shibb + Panopto + AD TokenGroups