[Shib-Users] POST SAML 2 assertion to SP
Don Woods
I have a SP(SP1) and I'm able to receive assertions from an IDP. Both these follow SAML 2.0. Now, I need to POST the assertion that SP1 received from the IDP to another SAML 2.0 SP. What is the best way to do this?
Thank you
Don
Scott Cantor
> these follow SAML 2.0. Now, I need to POST the assertion that SP1 received
> from the IDP to another SAML 2.0 SP. What is the best way to do this?
There is no way to do this with the SSO profile, it's improper to do it. If
you're working in some other context and the original assertion has
additional audiences and/or subject confirmations, that's a different story,
but at present, the Shibboleth IdP doesn't support that.
-- Scott
Don Woods
-Don
RL 'Bob' Morgan
On Fri, 12 Sep 2008, Don Woods wrote:
> In my case, I have a security context at the IDP and now wish to go to
> SP2. Is there a way so that I can send a SAML 2 assertion to SP2? Isn't
> this supported?
SAML assertions are created by IdPs and consumed by SPs. So for SP2 to
consume an assertion it needs to come from an IdP. You could make SP1
into an IdP also. But SAML has no provision for moving assertions between
SPs. In fact it has specific provisions against doing this, since it's a
security threat.
- RL "Bob"
Scott Cantor
SP2.
> Is there a way so that I can send a SAML 2 assertion to SP2? Isn't this
> supported?
Not in the way you described it:
> Now, I need to POST the assertion that SP1 received
> from the IDP to another SAML 2.0 SP.
Each SSO assertion travels from the IdP to the SP. The others SPs are
irrelevant. They don't exist for the purposes of the profile.
If you want to access multiple SPs, you just do it. The IdP will use the
profile each time you do so.
If you're asking how to do this without making each SP responsible for
issuing a request to the IdP, you can't do that at the moment. The present
IdP does not support SAML 2 via IdP-initiated SSO. There's no way to tell
the IdP to send an assertion other than to have an SP make a request to it
(or spoof one).
-- Scott
Peter Williams
Now, SPs **may** exchange certs, between themselves. Even if the SAML blob is NOT accompanied by an X.509 authorization cert, the OCSP response used to verify the SAML signing cert may. You can forward it, as a token satisfying whatever control paradigm you have, between RPs. Such certs may even be ephemeral and of short life. Ephemeral certs have a long history - in the IETF standards world - as an offline crypto control/enforcement construct (enforcing older, US compromise-grade crypto in SSL/TLS1.0 DH ciphersuites).
If one were to ignore OCSP and X.509 PACs, the signing cert that typically accompanies (by reference) a posted SAML Response is not part of the security context defined by SAML (in contrast to other security messaging standards). As far as I can tell, nothing binds SAML processing of websso profiled types to the certs distributed in (signed/controlled) SAML metadata.
Its worth remarking that Identity Certificates were always intended to be widely distributed without per-recipient controls (via public directories, cleartext messaging headers) and to be cached and replicated by forwarding intermediaries as they wander in the clear through open agent networks. The signing certificate can contain extensions of course, which profilers can and should define for themselves. You could even define your own SAML type from the base markup. Then...define a string extension for a cert whose value is the XML value.
You should be able to use the opensaml libraries on your Shib system to handle SAML tokens delivered by certs as extensios (or as TLS cert messages). Formally, using opensaml libraries for this, you are not using "shib", tho. You should call it something clearly unrelated, like "notshib".
In the openid websso world, RPs do communicate with each other, by design. An SP can update other SP, using services of the OP. Using the openid extension framework and a custom attribute-encryption OpenID auth extension, this RP-RP signaling of encrypted fields can even be under a security context that is NOT mediated by an OP/IDP. (I have to admit that I tend to think of this as a minor variant of the SAML SP affiliation model, where the change of name/attributes/entitlements by a primary SP is signaled to other SPs in the affiliation (via an IDP).
Peter Williams
"4.1.3.6 Service Provider Grants or Denies Access to
...
Any subsequent use of the <Assertion>(s) provided are at the discretion of the service provider and other relying parties, subject to any restrictions
on use contained within them."
-----Original Message-----
From: RL 'Bob' Morgan [mailto:rlmo...@washington.edu]
Sent: Friday, September 12, 2008 2:35 PM
To: shibbole...@internet2.edu
Subject: Re: [Shib-Users] POST SAML 2 assertion to SP
RL 'Bob' Morgan
> "4.1.3.6 Service Provider Grants or Denies Access to
>
> ...
> Any subsequent use of the <Assertion>(s) provided are at the discretion
> of the service provider and other relying parties, subject to any
> restrictions on use contained within them."
http://www.ai-lab.it/armando/pub/fmse9-armando.pdf
- RL "Bob"
Scott Cantor
>
> ...
> Any subsequent use of the <Assertion>(s) provided are at the discretion of
> the service provider and other relying parties, subject to any
restrictions
> on use contained within them."
You don't seem to grasp the meaning of the last clause. If you think that
gives you carte blanche to go forwarding targeted bearer assertions around,
then apparently an errata is needed.
-- Scott
Scott Cantor
> accompanies (by reference) a posted SAML Response is not part of the
> security context defined by SAML (in contrast to other security messaging
> standards).
It's out of scope what "part of it" it is. That doesn't make it "not part
of" it.
> As far as I can tell, nothing binds SAML processing of websso
> profiled types to the certs distributed in (signed/controlled) SAML
> metadata.
Well, other than common sense, the metadata specification, and every
implementation that uses metadata. It certainly is not true here.
> Its worth remarking that Identity Certificates were always intended to be
> widely distributed without per-recipient controls (via public directories,
> cleartext messaging headers) and to be cached and replicated by forwarding
> intermediaries as they wander in the clear through open agent networks.
So are (some) holder of key assertions. These are NOT.
-- Scott
Peter Williams
1. "but informal and bulky SAML 2.0 specifications." I find the language in SAML extremely tight and formal. It's some of the best I've ever seen for open systems work. Its less formal than the English language used in ISO security specs but much more readable. IETF security specs are more readable, but rarely a reflection of a type system. Depending on how deep a reading you want, the OASIS language allows for different grades of readers to appreciate the specification. Perhaps, you have to be a native English speaker to detect the quality of language used.
2. "Trust Assumptions. The protocol assumes that IdP is trustworthy for both C and SP, but SP is not assumed to be trustworthy." Wow! What an assumption to make. IS this really stated somewhere in the precepts of the OASIS websso spec?? In their use of the term "SSO protocol", I'll assume they really mean the authnReq protocol used in the websso profile. If I accept the trustworthiness assumption, it will be interesting to see how anyone rely on the authnReq signature? Presumably, the trustworthiness can never be a function of the assurance class of the supporting certs, if used, applied to such signed request. Again, this all very revealing about the websso profile (if the OASIS folks agree with the analyst's assumption).
3. in making the sub-assumption 'C and SP can be played by the intruder, while we assume that IdP is played by an honest agent' they are essentially treating the IDP under the same trust hypothesis as the issuing authority component of CAs (in the typical formal models of PKIs). I have to admit, this is a new perspective for me. I had always treated IDPs and SPs as peers, each supported by metadata (and signed data supported by certs of different assurance classes), where only the IDP can make certain classes of (standardized) statements (upon which RP's **perhaps** opt to rely).
4. A1 limits the analysis to TLS v1.0 (underlying Mozilla-compatible https, presumably). At this point, I've really no idea what their "unilateral" channel is (unless it's a SSL channel where one has done a half-close on one of the TCP channels?)
5. A2 goes into "bilateral" notions of SSLness, which apparently has something to do with SSL certificate checking (if and only if performed by particular classes of principal, defined within the formal entity model of SAML).
6. If you read it a few times, A2 does show that they are wanting to define a validity model of certs (which most forget to do). So, all credit to them for this. This is then defined in their unique terms I think (unilateral/bilateral), where validity is apparently defined as a semantic function dependent on SAML's entity model. Thus, the trust basis of the formal analysis REALLY does seem to be founded on there being a "custom profile" of TLS1.0 within Mozilla-https (tuned to the SAML authnReq protocol). The custom profile seems to be merely an analytical device, rather than anything concrete. (Its not obvious whether they intend their model to hold for TLS versions later than TLS 1.0.)
7. A2 has yet more trust modeling information. Crossing 4 layers (from AuthnReq to HTTP to https/pki to TLS1.0) the assumption seems to be wanting to define semantic validity in terms of an (implied) act of reliance (by C) on a PKI cert server chain (and CRLs/OCSP and the CRL/OCSP's own certs) and the IDP's reliance on/use of the user credentials from C (which of course SAML does not specify anything about, at all!).
I suppose this foundation is all quite proper, as they have essentially qualified the two main aspects of websso profile which lie formally outside the SAML spec ; but which must be analysed if an application context of authnReq plus its transports are to be formally addressed.
Does anyone disagree with their baseline??!
It seems to say that https is mandatory for websso, and the websso spec from OASIS cannot be understood in its absence. It then seems to say that only cert-based ciphersuites are valid, when supporting websso flows.
If they really only focused on Google's interpretation, I'd guess that both of these interpretations are reasonable things to do (since no doubt Google probably are only exploiting commodity-grade security services).
----------
If folks feel that their assumptions properly reflect what OASIS intended, I'll take a look at the formalism (as best as my limited capabilities allow)
I'm guessing already they will prove that Google omitted the mandatory audience field... when all is said and done. Given they define an SP (and all other RPs) as untrustworthy, and can therefore be assumed to act in a non-conforming manner, math will have proved that folks can (and usually do!) write non-conforming systems that fail to type-check the messages!
-----Original Message-----
From: RL 'Bob' Morgan [mailto:rlmo...@washington.edu]
Sent: Friday, September 12, 2008 4:54 PM
To: shibbole...@internet2.edu
Peter Williams
You the SP have discretion to communicate assertions to other relying parties who may use them. Everyone performing reliance is subject to the use limits expressed by the IDP (as reflected in the audience rules). If the IDP asserts nothing or little (via a null audience rule or a very wide-ranging audience), SP/RP discretion is therefore wide, and use is liberally controlled. An implementation/communty with a tight use model may well assert very specific limits (e.g. specify that the SP is the one and only one entity, via the audience control).
(leaving the parenthetical elements aside) isn't that what a reader is supposed to understand?
------
Does it also mean (and here I'm starting to reach) that cert policies and metadata policies ("incommon" the enforcer!) may also contribute to those "limits"?
-----Original Message-----
From: Scott Cantor [mailto:cant...@osu.edu]
Sent: Friday, September 12, 2008 5:04 PM
To: shibbole...@internet2.edu
Scott Cantor
> parties who may use them. Everyone performing reliance is subject to the
use
> limits expressed by the IDP (as reflected in the audience rules).
Audience is one thing, and confirmation method is the other. In the SSO
profile, that means you cannot authenticate to one SP with an assertion
issued to another unless you ignore the specification as an SP, or unless
the original assertion has two audiences, and has two subject confirmations,
each of which authorizes bearer delivery to distinct locations.
Or of course, you can run a proxy and have the first SP turn into an IdP and
issue a new assertion to the second.
This assumes that the use case is for the browser to authenticate to both
sites. If you're talking about n-tier, with the SP as client, that's a
different matter, and there are other additions that will enable that.
> If the IDP
> asserts nothing or little (via a null audience rule or a very wide-ranging
> audience), SP/RP discretion is therefore wide, and use is liberally
> controlled.
Yes. But that is not this case, so it's irrelevant. The reason it's not this
case is that doing that with bearer assertions is unsafe, and Shibboleth
will not and should not support this (at least not without a great deal of
knob turning and uncommenting big flashing <blink> comments saying it's
stupid to do it).
> An implementation/communty with a tight use model may well
> assert very specific limits (e.g. specify that the SP is the one and only
> one entity, via the audience control).
In this case, it's a consequence of the profile, unless you're prepared to
extend the assertion with the additional confirmation methods that would
safely allow for adding additional audiences.
Leaving that aside, we're talking about this implementation of the profile,
and at the moment, that isn't something we formally support. You can add
more audiences now, I suspect, but not the confirmation methods. Ergo, our
SSO assertions are not forwardable as SAML assertions.
> (leaving the parenthetical elements aside) isn't that what a reader is
> supposed to understand?
I don't read any of your earlier messages, to say nothing of the discussion
of certificates (none of which is required to make SAML work properly at
all), as consistent with this one.
-- Scott
Peter Williams
1. Analysing "The <SubjectConfirmation> element SHOULD be used by the relying party to confirm that the request or message came from a
system entity that is associated with the subject of the assertion, within the context of a particular profile."
If we treat the SHOULD as a MUST for the sake of argument, and we treat the SP as a **trustworthy** entity that does conform to SHOULD/MUST handling rules, we see from the definition that the main object of the control is to confirm that the assertion's originator is bound to the subject (in some way). This is not obviously a "per-recipient" control. It's apparently just like the old RFC 1422 IPKI rule which mandated that RPs should confirm that the issuing authority component of a CA has "legitimacy" to issue name assertions about subjects in some particular naming context. It insisted that RPs check subject DNs be subordinate to the issuer DN. (Later versions of X.509 standardized a far more flexible algebra than that simple dominance rule, so self-contained X.509 cert cahins could roam free (in SSL) of the authoritative, hierarchical naming context model of X.500 Directories.)
Nothing inherent in the *general* notion of "confirmation by SPs" implies a per-recipient control - requiring two confirmations for 2 intended recipients. Nothing in the text says it, either, or (easily) implies it. If we assume the websso profile later (legitimately) adds such per-recipient semantics (yet to be shown, in text), on processing a signed SAMLResponse an RP could well end up using confirmation doctrine A for certs and confirmation doctrine B, for SAML assertions.
2. Analysing "that the request or message came from a system entity that is associated with the subject"
If we take a longer look at that the cited line of the quote in 1, we note some interesting issues. First, it forces us to stop thinking of only SPs as relying parties. (Yes, in the original VeriSign CPS ultra-formal legal model, even a CA is a relying party!) Second, a relying party - in the sense of the very confirmation paragraph discussed in 1 - can be the IDP (and/or an IDP discovery agent). Why? Because it's an IDP that is handling a "request" - as that term is used in the grammar of very material quoted in 1. And, the obligation seems to being made on IDPs that they shall know their customer (SP), confirming that said system entity is "entitled" (my term) to a fulfillment of its request...for an assertion. That is, if the entity name of the SP is not known by an IDP to be a "legitimate" requester for the particular subject of the pending assertion, the IDP as relying party should not rely on the request, owing to lack of "confirmation". In response, it either just drops the request or issues a SAML error.
Am I stretching here, or am I right on the mark of what is INTENDED (after a deep reading)?
If I'm on the mark, one can go a bit further in attempting comprehension. In the IDP proxying model variant, one IDP shall still know its customer (another IDP) similarly. Also, a discovery agent may be required to "confirm" requests too, as a relying party, to determine that its authorized to perform discovery for a given SP. Said agent may limit its IDP discovery actions to the limits of the authorization granted (by parties unknown) to only certain IDPs, per SP entity (or perhaps some signal in the legitimate-SP's authnReq, such as the SP's signing cert's issue... or its assurance class?)
3. Analysing confirmation methods (line 323, section 3 intro)
We see in the notion of "methods" of confirmation that relying-parties may be given work to do. In some cases, as noted in the text, certs may be used during confirmation (e.g. an X.509 PAC cert) which may be specifically communicated within the SAML confirmation type. If so located, such certs are clearly intended to control the overall actions of the RP. Certs than merely accompany or are later attached to the signature on a request/response are less obviously destined for the SAML-machine's handling. IF the cert in the confirmation was to reference certs used in the signature process, and thereby limit their use, then I suppose one could say that SAML controls are are indeed controlling the onward forwarding of even those certs (and OCSP messages, and ... any other PKI construct) by the SP to other parties.
4. Reflection.
I have to say, reflecting all this analysis back on that formal methods paper cited by Bob Morgan, I fail to see how SPs can ever be properly treated (for viable formal methods analysis purposes) as __untrustworthy entities__ in the security model. The whole control plane design we are imputing here about SAML, from some pretty meager textual cues, implies a very correct SP - one assumed in almost a mandatory regime to be bound and conforming to some system wide security policy in handling not only assertions but certs of various types (id vs PAC), their various authority delegation constructs (particular for Entrust-managed PACs) and then their general assurance classes.
-----Original Message-----
From: Scott Cantor [mailto:cant...@osu.edu]
Sent: Friday, September 12, 2008 7:59 PM
To: shibbole...@internet2.edu
Subject: RE: [Shib-Users] POST SAML 2 assertion to SP
Peter Williams
What discretion there is... would seem clearly to be controlled by the IDP. Per (see below), an SP can clearly request additional audience elements (somehow) which the IDP may or may not incorporate.
As I read all this more and more, one has to take a term (like discretion) and follow it through multiple sections, to see how the underlying, essentially-mandatory controls in the security model hold together. The security model is the gestalt of all the handling rules.
-----Original Message-----
From: RL 'Bob' Morgan [mailto:rlmo...@washington.edu]
Sent: Friday, September 12, 2008 4:54 PM
To: shibbole...@internet2.edu
Scott Cantor
the
> SP as a **trustworthy** entity that does conform to SHOULD/MUST handling
Trust has nothing to do with this. The SP is protecting *itself* by
following the specification and not accepting assertions that are clearly
being misused. That doesn't require anybody else trust an SP, it requires
the SP not behave in a patently stupid manner for its own good.
The issue is not what you can do with an assertion, the issue is whether the
entity you give it to has any business accepting it.
When somebody asks a perfectly reasonable question like the originator of
this thread did, you don't answer that by assuming the SP is non-conforming.
That would be stupid. You assume that the SP conforms to the rules that
exist for the SP's own protection, and answer accordingly that it will
reject an attempt to reuse an ordinary targeted assertion, so you can't do
it.
> rules, we see from the definition that the main object of the control is
to
> confirm that the assertion's originator is bound to the subject (in some
> way). This is not obviously a "per-recipient" control.
If an assertion is issued such that it can only be confirmed when it's given
to a particular SP, that's per-recipient control.
> Nothing inherent in the *general* notion of "confirmation by SPs" implies
a
> per-recipient control - requiring two confirmations for 2 intended
> recipients. Nothing in the text says it, either, or (easily) implies it.
Try the Recipient attribute, which is highly relevant when you're talking
about bearer confirmation.
> 1. And, the obligation seems to being made on IDPs that they shall know
> their customer (SP), confirming that said system entity is "entitled" (my
> term) to a fulfillment of its request...for an assertion.
That is not a requirement.
> That is, if the
> entity name of the SP is not known by an IDP to be a "legitimate"
requester
> for the particular subject of the pending assertion, the IDP as relying
> party should not rely on the request, owing to lack of "confirmation".
Confirmation is not associated with requests, it's associated with
assertions. If an assertion is attached to a request, then confirmation
comes into play.
> I have to say, reflecting all this analysis back on that formal methods
> paper cited by Bob Morgan, I fail to see how SPs can ever be properly
> treated (for viable formal methods analysis purposes) as __untrustworthy
> entities__ in the security model.
That depends on the purposes of the analysis. If you give an assertion to
one SP and the threat you're addressing is whether that data will be exposed
to another, then it's quite obvious you're trusting the SP. If the threat is
whether the assertion, if given to a different SP that is attempting to
follow the rules, will successfully authenticate the user (a MitM attack),
then the "misbehaving" SP need not be trusted.
-- Scott
Peter Williams
In classical (DoD) security analysis for internet communications systems, a "trustworthy" entity is one who the disclosed security model treats as a party intending to be conforming to the security policy. The party is not assumed to be inherently hostile; though is protection boundary may become compromised. Why that protected party is subscribing to centralized trust regime, or whether it's a good posture or not for their interests, is not addressed in a classical "security model". They are assumed in the model to be a member of the coalition of the willing. An accreditation risk scoring processes used when composing systems and sub-systems of different trustworthiness (e.g. NCSC Red Book) can and would later consider such environmental factors, per theatre of actual operations. Now, perhaps I'm falling into pedanticism, and being overly terminological, distinguishing "security models" from "accreditation". Using such terms in the formal trust modeling really does just depend on the security doctrine one is trained in; they are not a substantive basis of argument.
Despite your points, I do (still) think we have to decide whether SPs (and other relying parties downstream from the SP) are trustworthy, in the SAML entity model sense. Then, we have to decide "just how conforming" a trustworthy entity really needs to be, even after the SAML flow is concluded. To help understand governance, in the very novel SAML world, let's see for a bit just how far authorization policy projects from an IDP. Does its reach beyond the SAML flow, for example?
We can stipulate that SAML controls (through audience and confirmation signals) MAY indeed limit the flow of any C to SP token (in any container) during websso, and the IDP is supposed to be guard over such information flows through its per-recipient mechanisms. And, we know the IDP has discretion, enacted through proxy and audience controls in one or more SAML responses or assertions, to facilitate use of a token, once delivered within the authorized window to the downstream entity (another IDP, or the terminal SP). But we also know, from phrasing in the text, that the security context ultimately created between C and SP via websso is 100% controlled by the SP - following the SP's local grant/deny action. Unlike CAs that "delegate" issuing/reliance rights to OCSP servers (using a take/grant authorization model tuned to "information flow" security models), IDPs do not obviously "delegate" rights to an SP: they merely provide assertions (with authorization info and IDp-discretionary limits on reuse). Quite reasonably, one can argue that the authorization limits SHOULD hold for at least all contents in, and/or contents in certs/cert-chains directly referenced by, the assertions.
In a highly controlled information flow policy, it does seem correct and in scope that the SAML assertions COULD be controlling the certs, the trustpoints and the ciphersuites used in the https channel between C and SP - at least up to the point of delivery of assertions - and/or other conclusion of the particular SAML protocol run. Arguably, the assertion could even be controlling the flow of messages of the SSL handshake of that bearer session too, should one uses DoD's option to replace ASN.1 certs in TLS 1.1+ client auth with (a set of) SAML assertions (whose confirmations fields may include ASN.1 Certs!). Generalizing, an assertion could be deemed to be controlling the bearer's SSL session too, its own use of CONNECT during SSL proxying, upto even the entire hypermedia context of the https-association in which C is engaged, simultaneously, with 1 or more SPs.
But, is it the Shib communities intention that SAML could subsequently be controlling information flow during the C to SP security context, post websso? For example, the SP's SSL server's authorization might immediately initiate a new SSL re-handshake, propose new CA trust points, negotiate a new client cert, and establish a new ciphersuite on the very same TCP connection (and SSL session/connection) that was just used to bear the flow of assertions on the websso protocol run. Does the shib concept intend that SAML's scope of control might include that subsequent SSL re-handshake, too?
The real thrust of the issue of token forwarding has turned from mere information forwarding controls into a generalized control and governance issue, I think. Is SAML/websso intended to be a wide-ranging control and governance framework, for all information flow operating at many layers in the stack and in the MEPs that will follow websso? Or is it merely a simple session translator, moving attributes from one server-side session store to another? (*)
Deployed ADFS in win2008 data center edition limits itself in this area, we might note. While Ws-Fed passive can indeed and does embedded pass rights-management tokens around - that control DRM-like applications behavior on the windows desktop to as fine a level of discretion as Sony US could ever dream of - the federation protocol itself is merely a conduit between app and rights management authority. WS-Fed itself know nothing of, and has no role in, control and governance beyond creation of a new session/security-context between C and SP.
(*) Kerberos had the same dilemma of course. In DoD doctrine, Kerberos enforced the connection-oriented paradigm ; invoking the Red Book's model of trust composition. In commodity systems, it just did student logon via sso to file systems, directories and print servers.
-----Original Message-----
From: Scott Cantor [mailto:cant...@osu.edu]
Sent: Saturday, September 13, 2008 11:11 AM
To: shibbole...@internet2.edu
Subject: RE: [Shib-Users] POST SAML 2 assertion to SP
Scott Cantor
> controlling information flow during the C to SP security context,
> post websso?
No, nor have I said anything to the contrary. This is about *SAML*
forwarding, nothing else.
-- Scott
Peter Williams
Im thinking that the sp will put the assertion in the ephemeral server cert it generates, when doing a rehandshake with the sslclient on the same ssl session as used earlier to transfer the bearer assertion. This way, one has good assurace that only the user has access to the bearer assertion.
Only question is, can the user properly "use" it, as a relying party, in the saml rule system?
Seems silly functionally to deny the user access to their own assertions. But plenty of security models do that (the user does not own or have rights on tokens about themselves!, being untrusted). This notion is of course the genesis of the uci/openid movement, which denies such regimes ( the user always has access/reuse rights to such tokens in uci doctrine).
Scott Cantor
> assertion?
The user is the one who presented it. Aside from the IdP encrypting it,
which has its detractors, you can't prevent that access. If you mean "allow
the user to use it anywhere without constraint", no, that's not how security
protocols work.
> Im thinking that the sp will put the assertion in the ephemeral server
cert
> it generates,
I have literally no idea what you're talking about.
> Seems silly functionally to deny the user access to their own assertions.
That has been used as an argument against XML encryption.
> But plenty of security models do that (the user does not own or have
rights
> on tokens about themselves!, being untrusted). This notion is of course
the
> genesis of the uci/openid movement, which denies such regimes ( the user
> always has access/reuse rights to such tokens in uci doctrine).
Political "control" has very little to do with technical control, and who
issues or controls an account and who's allowed to decide where it's usable
are totally separate from the technical controls at runtime in a security
protocol.
I would certainly be interested to learn that the OpenID protocol (which
FWIW I don't believe even has the notion of a separable token) is issuing
bearer credentials by design that can be reused at will. Because that would
be the end of OpenID, trust me.
-- Scott
Spencer W. Thomas
Scott Cantor wrote:
> If you want to access multiple SPs, you just do it. The IdP will use the
> profile each time you do so.
>
> If you're asking how to do this without making each SP responsible for
> issuing a request to the IdP, you can't do that at the moment. The present
> IdP does not support SAML 2 via IdP-initiated SSO. There's no way to tell
> the IdP to send an assertion other than to have an SP make a request to it
> (or spoof one).
>
Maybe I'm missing something. User has authed to SP1. SP1 wants to
"auth" user to SP2. Assuming SP2 has a session initiator URL, could not
SP1 craft such, referencing the IdP and redirect the user there? I
don't know if this addresses the original use case, but it seems to me
that it does address the case of "forcing" SP2 to ask for an assertion
from the IdP.
> -- Scott
>
>
>
--
Spencer Thomas
Lead Software Developer, JSTOR
spencer...@jstor.org <mailto:spencer...@jstor.org>
+1-734-887-7004
JSTOR is a not-for-profit organization helping the scholarly community
take advantage of advances in technology. Our initial effort -- building
trusted digital archives for scholarship -- provides for the long-term
preservation and access of leading academic journals and scholarly
literature from around the world. Our work is supported by libraries,
scholarly societies, publishers, and foundations.
Don Woods
--don
Scott Cantor
> "auth" user to SP2. Assuming SP2 has a session initiator URL, could not
> SP1 craft such, referencing the IdP and redirect the user there?
Sure, but the result is that you're asking SP2 to make its own request to
the IdP, which is what I was saying you had to do.
> don't know if this addresses the original use case, but it seems to me
> that it does address the case of "forcing" SP2 to ask for an assertion
> from the IdP.
It was designed to make that as easy as possible while hiding the details of
what the request needs to contain, yes.
My problem with IdP-initiated SSO is that it makes the IdP responsible for
knowing a lot of details that the SP can normally just tell it, so I figure
why not just let the SP tell it.
-- Scott
Spencer W. Thomas
<https://spaces.internet2.edu/display/SHIB2/NativeSPSessionInitiator>.
The SP2 then can bypass the discovery service and send the user straight
to the IdP with the appropriate return parameters. The SP must support
a session initiator URL, of course.
For example, a publisher who wanted to link a user into JSTOR,
"pre-authorized", could build the URL:
http://www.jstor.org/start-session?entityID=provider-uri&target=target-url
Assuming, of course, that the user *can* authn to both the publisher and
JSTOR with Shibboleth, and that the user *has* so authned to the
publisher, so that he publisher has the user's provider-uri.
If you can login to Ohio State's IdP, this URL will take you to a
specific article in JSTOR, and if you've previously logged in through
their IdP, you'll go "straight" to the article (visually, anyway -- your
browser will go through some gyrations to get there).
If you're curious, the article is
The Biblical Shibboleth Story in the Light of Late Egyptian Perceptions
of Semitic Sibilants: Reconciling Divergent Views
Journal of the American Oriental Society, Vol. 123, No. 2 (Apr. - Jun.,
2003), pp. 271-289
> <mailto:spencer...@jstor.org <mailto:spencer...@jstor.org>>