Installation Resources

Fred Newtz (frnewtz) frnewtz at cisco.com
Fri Feb 10 16:50:30 EST 2017


Scott,

This is really only internal documentation for our team.  Having said that, I would definitely like a link or a copy of the template you are speaking about here as I can pass that on to our documentation team who can put up a page on Shibboleth on our website.

I hope I didn’t give the impression of complaining about the documentation.  That was never my intention although I can see where it came off that way.  None of this is easy or else everyone would be doing it.  This is not the first time I have run into issues trying to figure out how to configure various platforms.  It just takes time and patience to figure it out.  Once you do figure it out though then that ah-ha moment sets in and everything finally makes sense.  I look forward to that day with Shibboleth.

Thanks,

Fred 


On 2/10/17, 2:28 PM, "users on behalf of Cantor, Scott" <users-bounces at shibboleth.net on behalf of cantor.2 at osu.edu> wrote:

    On 2/10/17, 4:10 PM, "users on behalf of Fred Newtz (frnewtz)" <users-bounces at shibboleth.net on behalf of frnewtz at cisco.com> wrote:
    
    >I am working on documenting the integration of Shibboleth IdP with a third party SP.
    
    But you really should *not*. I cannot say enough how non-helpful that is to the community, because you are not in a position to maintain documentation on how to do anything with the IdP and it will fall out of date and further confuse matters later on when people run into it.
    
    Your goal is best met by ignoring Shibboleth entirely from the perspective of your documentation and documenting your *SAML* requirements. I created a template for that [1] and it would be a hugely appreciated step for any vendor(s) to actually use it.
    
    Let *us* teach people how to make the IdP support your service (we'll add examples to the guide when it's done). Just tell us what the SP requires, and ideally listen to feedback if we have reasons for believing it's doing anything wrong, though that's purely a bonus.
    
    For that matter, if you do that, *we* can probably help you get it working too because then at least we know what you're trying to do with it.
    
    > Just an order of operations for configuration honestly.  If the links in the documentation are already in that order then
    > great.  I will keep plugging along until I get a win here.
    
    The Configuration page's list of topics is at least generally layered in a "foundation" -> "higher layer" fashion, but there is no magical order I know of to give people. I already identified the main areas that most people see as primary.
        
    > I love the aacli tool.  I was able to make a query, but it just returns the URL.
    
    If there's no logging, then that usually means you are not running it on the localhost with the IdP open to port 80, and it means you have to override the default URL it's going to hit to run the service endpoint. The output in that case sucks, the tool is very low tech, but the only way to have that happen is by not following the assumptions about installation the documentation is making.
    
    > Yes!  I definitely agree.  That is definitely more of a how-to document.  That would be an awesome link to have though!
    
    It doesn't exist.
    
    -- Scott
    
    [1] https://wiki.shibboleth.net/confluence/display/IDP30/IntegrationGuides
    
    -- 
    To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
    



More information about the users mailing list