Date: Tue, 19 Mar 2024 10:29:39 +0000 (UTC) Message-ID: <1979274506.1166.1710844179619@ip-10-10-7-29.ec2.internal> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_1165_1391768168.1710844179617" ------=_Part_1165_1391768168.1710844179617 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
A typical IdP today tends to be configured with an authentication mechan= ism that is relatively indifferent to the identity of the user or service. = A few deployments will implement the ability to choose from among a couple = of different login technologies, and a smaller number might actually levera= ge the identity of the service to determine what to do, such as offering a = PKI or multi-factor UI for a high-value application.
The use of assurance is an evolution in the maturity of these approaches=
that generally needs to know more about the service and the user to do the=
right thing. In this case, the right thing includes getting the right IAQ =
into an assertion's <saml:AuthnContext>
element. It may =
also include limiting or altering the behavior of the UI, but this varies d=
epending on the deployment.
As a couple of examples, consider two common cases:
If we consider the implications of the latter case, note that users will= likely expect the option to stick with a password unless they interact wit= h a service requiring the higher assurance level. This means the IdP needs = to know how the user has already authenticated, if at all, and the identity= of the service and its assurance requirements. Contrast that with the form= er case, in which a single mechanism is used regardless. Obviously this is = simpler, at the cost of imposing tougher password requirements on all users= .
Finally, consider that in either case, the user's actual assurance level= may well depend on directory information recorded about the user reflectin= g the identity proofing done. That information might even change based on a= remote password reset that temporarily lowers the assurance level. It is l= ikely that the IdP will need to consult this information before determining= the actual IAQ it can assert. This is in general not something that most s= oftware does "out of the box" today.
At the SAML layer, it has been assumed that if <saml:AuthnConte=
xt>
is used to carry assurance information, then the best user ex=
perience would be obtained if the SP simply specifies its desired IAQ in it=
s authentication request. This is complicated by a few considerations:
To move forward we will be collecting use cases and identifying best pra= ctices as we learn more about the problem.
We know that most IdPs today will have to adjust their behavior to some = degree to incorporate support for assurance. This will in most cases involv= e customizing the IdP via mechanisms specific to an implementation (see bel= ow for some more on this). Over time, we would expect to see some commonali= ty in these extensions and can provide exemplars.
We know that a lot of implementations don't have full support for the SA= ML features involved and conservative choices will have to be made, though = these may be balanced against the likelihood that doing anything may requir= e some degree of customization anyway.
If an IdP receives a request from an SP that does not include a &l=
t;samlp:RequestedAuthnContext>
element (that is, doesn't ask for =
a particular IAQ), it is free to more or less choose any authentication app=
roach and supply anything in the response that it chooses, as long as it's =
accurate in what it tells the SP.
Alternatively, an SP can ask for any of a set of "matching" authenticati= on context classes (which we use to express IAQs), with the matching based = on one of a set of predefined rules.
The most common, the default, and about the only one implemented at all,= is "exact". It means "exactly" that. The response from the IdP must includ= e one of the values requested, and it must match exactly, not by means of a= n "equivalence" test. For example, if the SP asks for "A", and "B" is just = as good, the IdP cannot use "B", but only "A. Of course, the IdP is expecte= d to only do this if it actually can. If the user can't au= thenticate well enough or their account doesn't qualify, then it can't fulf= ill the request. An error is defined in SAML to signal this result to the S= P, which is expected to handle the outcome.
The other matching rules defined are "minimum", "better", and "maximum".= Their definitions can be found in Section 3.3.2.2.1 of the SAML Core spec= ification. They have not seen wide adoption, and most IdPs would requir= e customization to handle them. "minimum", if any, is the one likely to see= interest in the future.
Yes, and no, respectively. An SP can enumerate a set that it supports, b= ut the IdP has to pick a single one. As a result, either rules within an ap= plication generally have to handle the relationships among IAQs, or it woul= d need to request only a single one and require all IdPs to return only tha= t value.
Both options can work, but have their advantages and disadvantages. If t= he SP handles the problem, then it must be configured with all of the possi= ble IAQs it can accept, and may fail to accomodate new values until modifie= d to do so. Relying on IdPs to accept all the values they can satisfy relie= ves the SP of this problem, but means more complex rules (and probably cust= om code) for the IdP. In practice, while there are more SPs than IdPs, SPs = tend to be easier to modify with new values.
It is possible in theory to define "super-IAQs" that operate above the l= evel of a single one and express combinations or alternatives, but in pract= ice this doesn't scale well, and produces essentially the same outcomes any= way.
Not technically, but some form of authentication contex= t does. An IdP could use an IAQ, or could fall back to older practice, pass= ing specific technologies back instead. For consistency, using the SAML-def= ined constant "urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified" is a goo= d idea.
The documentation available for the IdP's authentication support is avai= lable on the Shibboleth wiki..
For information about configuring Shibboleth IdP to support specific use= cases to support InCommon's profiles, see contributed documentation on thi= s wiki:
In a nutshell, the IdP defines a concept called "authentication method" = that is analagous to the concept of an authentication context class, and th= us an assurance qualifier. "RelyingParty" definitions in the IdP can carry = a default method that stands in for a specific requested value from an SP. = The result is used to identify one of a set of installed login handlers to = use for the request. The built-in handlers are limited to very simple use c= ases in which a fixed value is passed back from the handler identifying a s= ingle method, and that method ends up in the resulting assertion.
The "exact" matching type is supported, and a given login handler can be= associated with multiple methods so that different requests can succeed. H= owever, the built-in handlers cannot themselves pass back any but a fixed v= alue, which will simply cause an error if the request was for a different v= alue. In other words, some of the machinery supported is specifically desig= ned for use by custom login handlers and not the built-in examples. The exc= eption is the handler designed for plugging in "external" authentication sy= stems like a separate SSO system. This approach allows for some degree of c= ustomization already.
In addition, the IdP does two things worthy of note:
<NameID>
Form=
at
.The latter means that SSO is more likely, but that specifying a stronger= method first doesn't necessarily mean it will get used, even if the user c= ould in theory satisfy it. It also means that including "unspecified" in a = request will imply that any active authentication method for the user will = potentially get used before any stronger method would have the chance to be= evaluated, even if the stronger method were placed earlier in the requeste= d list.
As of V2.3.4, all handlers must signal the method used back to the IdP, = to prevent certain security problems when handlers of different kinds are a= vailable. Older versions work, but are likely to behave correctly only in c= ertain cases depending on the mix of handlers installed.
The simplest way to extend the IdP and ensure control over what happens = is by installing a single custom login handler that itself contains all of = the logic needed to differentiate what to do based on the SP, the request, = and the user. The handler can be associated with as many "methods" as neces= sary to cover all of the possible values involved, and the IdP will know to= invoke it in all cases. Alternatively, if the release is new enough, you c= ould isolate support for different methods into different custom handlers i= f you prefer that approach.
In any case, if the resulting assurance value depends on information fro= m among the user's attributes, then a custom login handler is probably requ= ired, because none of the existing handlers have support for invoking the a= ttribute resolution step in the IdP.
There is an unsupported example of a custom login handler that includes = attribute resolution on the Contributions p= age under "Stateless Cluster SSO". It does not explicitly deal with assuran= ce, but is itself extensible.
Questions about how to use the IdP to support assurance can be directed = to the users@shibboleth.net mailing list.