Shibboleth Developers

[Peter Williams <>]

I come at the design problem from the angle of LIMITING what an authority can 
do to CONTROL - since human nature seems intent on controlling others 
(perhaps dressing up that desire for control as a "compliance service" 
necessary for _scalable_ trust fabrics). But the necessity is not proven., in 
my view. As the SAML2 world gets more interconnected, I suspect we will 
observe what we saw over almost two decades in the SSL adoption space  - 
where certain traditional [crypto compliance] authorities first attempt to 
reinvent themselves as CAs (hoping to the one's that would survive and 
subsume all the others). As such reinvention strategies failed, the field of 
old business attempting to reinvent their value points did succeed to at 
least becomes an ever smaller set of authorities (as folks progressively 
dropped out) - allowing specifically SSL-centric and web-specific governance 
notions to evolve out of the web-ooze. 

In the case of SAML2, we already have chaining of IDPs (though Shib doesn't 
support formal IDP proxying). In one commercial deployment of chained IDPs 
(not SAML2 complying), Shib is one of several IDPs that a downstream "user 
centric" IDP talks to ... to get authentication assertions, attribute 
assertions, and authorization assertions (without bothering with the querying 
protocol modes, in general.) The normal sp-initated websso flow puts the 
user-centric IDP in control, allowing it to seek out assertions from other 
IDPs (who may in turn chain off further queries, much like a X.500 chaining 
network!). The policy on which agent is consulted under what condition and 
particular authorization policy governing access to a SP-side resource is a 
matter of negotiation between that "user-centric" IDP and its SP network 
(just like in X.500 "knowledge" directs discovery of agents authoritative for 
naming contexts, or active-directory used Kerberos transitive trust to 
federate multi-mastered attribute "partitions" in a forest of domains, or 
X.509 cross-certs allow for cross-forest data replications...). 

For example, if the auth-context requirement from an SP requires 3-factors, 
the gateway IDP may (1) ping back the facebook IDP (using connect protocol), 
(2) ping back the google IDP (using the firm's discovery-enhanced openid2 
protocol), (3) ping back ADFSv2 (using SAML2P in IDP lite profile). The 
various claims from those async-communicating parties (if any) are sorted and 
qualified, and merged for presentation to the particular SP -  though the 
origin of the claims may be retained (should the SP have expressed a desire 
to care about the origin). Obviously, SHib2 can substitute for ADFSv2 - 
seeing as it's just a SAML2 implementation.

This policy design space model doesn't sit too well with all parties - 
particularly those IDPs still in the business of "controlling compliance". 
Typically, they have an [older] business model that seeks to impose a 
"network-wide" policy on the SP - and they see it it as their ordained role 
to "govern". In the inverted model, in contrast, the user-centric IDP governs 
and mediates the flow of assertions between upstream (IDP) sources and (SP) 
sinks - much like an edge router governs namespaces and routes. This make it 
all "very internet." (So, who is in charge - the network or the host?)

In the Shib-participating deployment I'm thinking of, the best I could do to 
comply with SAML2 was chain two SAML2 sessions back to back - rather than 
perform complying IDP proxying. For all it mattered in a session chaining 
design, this IDP "gateway" could have been talking SAML2 protocol to an 
upstream ADFSv2+AD IDP (rather than Shib+AD), while talking ws-fedp to the 
Azure-hosted SPs on the downstream session. As a session mapper, the IDP 
gateway is acting much as does an SSL/https CONNECT Proxy - binding together 
2 crypto sessions (aka SAML2/ws-fedp sessions). 

As in the case of https CONNECT, local policy control can be used for 
relative good or for relative evil: to impose flow controls at the juncture 
that enforce a network-wide governance regime, or to insulate SPs from such 
"governing tendencies" by limiting such authorities to assertion minting 
roles. Again, as with CONNECT, there can be a sequence of such "local" 
control points on any WAN-scale writer-to-reader trust path - allowing for 
scaling of trust policys in an otherwise ungoverned communication/assertion 
fabric.

-----Original Message-----
From: 

 
[mailto:]
 On Behalf Of Paul Hethmon
Sent: Tuesday, September 07, 2010 5:12 PM
To: Shibboleth Dev
Subject: Re: [Shib-Dev] IdP-side authorization or other post-authn processing

On 9/7/10 7:48 PM, "RL 'Bob' Morgan" 
<>
 wrote:

> It is most likely within the capabilities of a site-developed login 
> handler to do this kind of thing.  It may be an issue that as far as I 
> know a single login handler gets invoked per request, so having a 
> potentially large set of post-authn checks would mean modifying the 
> login handler for each one.  Perhaps some way of chaining handlers 
> would be useful.

Bob,

This is essentially what I do in my commercial offering. My login handler 
receives additional information about the user during authentication. In my 
case, it's stuff like the user needs to go to the enrollment agreement or 
this user must change their password now. Based on that information, the 
login handler can make a decision about whether to have Shib establish a 
session or redirect the user to an alternate location.

It sounds like you have a larger potential pool of alternate things to have 
the user do and/or check about the user than I do. It seems that either 
hooking into the authentication process and having it return the information 
would work at the expense of a potentially complex set of requirements and 
conditions. Your idea of chaining login handlers sounds feasible too. The 
first one in the chain might do the actual authentication while the 
subsequent ones might only check authorization factors.

It would be possible to build that chain yourself I think as well. So your 
Shib login handler gets the authentication request from Shib and does the 
base authentication of the user. It then goes through its configured 
"sub-handlers". Those could be loaded via Spring or you could go a simpler 
route, something like just reading either context parameters or a separate 
configuration file for a list of sub-handlers. Make them implement the 
interface you design that gets the available information and returns the data 
necessary for the main login handler to make a decision.

One thought here. If a user who is restricted to some SP by policy first 
establishes a session with an allowed resource, what happens if they use SSO 
to then establish a session with the dis-allowed resource? To be complete, it 
seems you might have to either hook in or replace the previous session login 
handler. Otherwise, on an SSO request, the user would never see your login 
handler code executed.

Hmm, can you release attributes to that cloud service that either allows the 
user access or denies access? So put that issue outside of the login handler. 
For your use cases, it then looks simpler, has the user agreed to the 
necessary agreements, if not, force them.

Just some thoughts, there are always ways to skin the cat.

Paul