Getting started with JS client

[Cantor, Scott]

On 9/23/15, 2:58 PM, "users on behalf of Ben Allfree" <users-bounces at shibboleth.net on behalf of ben at name-coach.com> wrote:


>
>In that case, do you know what the best resource would be for a step-by-step walkthrough of an Apache "hello Shib"? I'm imagining a bit of PHP (or other) login form that authenticates to a test auth authority of some kind.

There are IdPs and SPs. IdPs have login forms. SPs don't (well, applications often do, but that's because people deploy federation badly).

A Shibboleth SP works differently than what you're going to expect, you're approaching this from the application developer end, and the Shibboleth SP is a web server module that moves this piece out of your space. It isn't PHP, it's not Python, it's not Java. If you want a library, you will need a different SAML SP implementation.

There isn't any profound difference from the Shibboleth SP point of view between "hello world" and "giant application fully integrated with it". You have to do 90% of the same work. That means it will look painful to get working, but once it's working, the rest is not going to have much to do with the SP.

> This feels quite different from oAuth and similar SSO, so I'm a bit out of my element :)

There are, I'm sure, Apache modules for OAuth out there. Those would be closer to the SP than anything else that implements SAML is. It's the design more than the protocol.

The best general discussions of how the SP "works" are:

https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPEnableApplication
https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPAttributeAccess
https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPApplicationModel


The SAML part is largely separate from that aspect of the design, it's all hidden from the application. Without knowing what deployment model you're investigating, it's hard for me to say much about that part that will make any sense to you.

The enterprise model of using SAML is point to point and driven by application silos that are connected to specific customer IdPs. That's not federation, it's just offloading authentication with a standard protocol. Federation requires that an application actually deal with multiple IdPs at the same time for the same resources. Few commercial services support that.

The higher ed model for SAML that Shibboleth represents is designed around having thousands of IdPs and SPs that connect through federations that manage the exchange of their metadata so they don't have to directly deal with each other up front for every relationship to work. It automates some aspects of change management and handles key rollover, which is a manual issue in most enterprise deployments.

Shibboleth is exclusively metadata driven. You need SAML metadata describing any IdP and SP that are working together to make the software work.

The basic recipe for an SP is to assign it an entityID that will never change, supply it with metadata about the IdP(s) it needs to handle, give the SP's metadata (its entityID, endpoints, and keys principally) to those IdPs, define a simple protection rule in Apache to trigger a login, and test it.

Operating in the various higher ed federations, all of that metadata exchange is handled for you and it's extremely simple. Without that crutch, it's more complex.

You caught me on a verbose day.

-- Scott