Single site Id hosting multiple SPs

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

Single site Id hosting multiple SPs

Sohail Bashadi

Hi,

 

We have a scenario where we are trying to serve multiple SPs on a single server. I was wondering if there is any way to setup multiple SP’s that point to different IDP’s with a single Site Id?

 

Thanks,

Sohail

Reply | Threaded
Open this post in threaded view
|

RE: Single site Id hosting multiple SPs

Cantor, Scott E.
Sohail Bashadi wrote on 2009-01-21:
> We have a scenario where we are trying to serve multiple SPs on a single
> server. I was wondering if there is any way to setup multiple SP's that
> point to different IDP's with a single Site Id?

Almost certainly but your terminology is off, so I can't tell what you're
trying to do. Pointing to different IdPs for different resources is trivial,
you just stick an entityID setting into the RequestMap or an htaccess file
for the content you want to "pin" the IdP for.

That isn't a "multiple SP" use case, so like I said, your terminology is
off. I advise you to ignore SAML terminology and just describe what you're
trying to do.

-- Scott


Reply | Threaded
Open this post in threaded view
|

RE: Single site Id hosting multiple SPs

Sohail Bashadi
Thanks! For responding to my query. I was afraid I was not describing
well what I was trying to do. So, here is the scenario of what we are
trying to do:

We are an ASP with multiple customers running on the same server; using
the same code base. In our production environment we provide unique
customer URLs; so we assign unique external IP address to each customer
URL and have unique a site Id for all customers in IIS. This also allows
us to point each customer to their respective IdP. That is all fine and
dandy; but in our test environment we have a slightly different setup.
All customer test sites have a single external IP Address; so we only
have one entry in IIS and we use host headers to load the appropriate
content for each customer. Since the Shibboleth Daemon needs a unique
site Id for each protected resource in Shibboleth2.xml; I was wondering
how I can implement Shibboleth on the test server for these customers
using the existing single site entry in IIS?

Thanks,
Sohail

-----Original Message-----
From: Scott Cantor [mailto:[hidden email]]
Sent: Thursday, January 22, 2009 9:59 AM
To: [hidden email]
Subject: RE: [Shib-Users] Single site Id hosting multiple SPs

Sohail Bashadi wrote on 2009-01-21:
> We have a scenario where we are trying to serve multiple SPs on a
single
> server. I was wondering if there is any way to setup multiple SP's
that
> point to different IDP's with a single Site Id?

Almost certainly but your terminology is off, so I can't tell what
you're
trying to do. Pointing to different IdPs for different resources is
trivial,
you just stick an entityID setting into the RequestMap or an htaccess
file
for the content you want to "pin" the IdP for.

That isn't a "multiple SP" use case, so like I said, your terminology is
off. I advise you to ignore SAML terminology and just describe what
you're
trying to do.

-- Scott



Reply | Threaded
Open this post in threaded view
|

RE: Single site Id hosting multiple SPs

Cantor, Scott E.
Sohail Bashadi wrote on 2009-01-22:
> All customer test sites have a single external IP Address; so we only
> have one entry in IIS and we use host headers to load the appropriate
> content for each customer. Since the Shibboleth Daemon needs a unique
> site Id for each protected resource in Shibboleth2.xml;

That's incorrect. The Shibboleth Daemon is also irrelevant, it doesn't even
know about the web sites.

The SP relies on Site ID -> hostname mappings to canonicalize the hostname.
If you want a single site to support multiple hostnames, you'll have to use
the <Alias> element inside the <Site> to add the additional hostnames you
want.

That will authorize clients to use different hostnames and preserve them for
mapping purposes. Of course, nothing in such a setup prevents a client from
sending any hostname it wants. As long as you're not trying to create access
or security rules based on that, you're fine. Using it to default to the
right IdP is perfectly reasonable.

Essentially, your two scenarios are the same. From the SP's point of view,
you could lump every single customer into one SP and one default application
with a bunch of different endpoints for each host. Within the RequestMap,
putting an "entityID" property in the Host will route them to the right IdP.

The only difference in the two situations is how the Site/Host mappings are
done. In one case it might be a bunch of Sites and in the other one Site and
a bunch of Aliases.

Now, if you want things to be complex, you can make it much harder by
creating different SP entityIDs for each host, but if it's one app serving
the same basic service, I really wouldn't do that.

-- Scott


Reply | Threaded
Open this post in threaded view
|

RE: Single site Id hosting multiple SPs

Sohail Bashadi
Thanks! For the response; I think I mostly understand what is being
suggested here. I am not clear on how to implement this; the only thing
that I saw close to an example is the following:

<Implementation>
<ISAPI normalizeRequest="true">
<Site id="1" name="dev.purchasing.ucla.edu">
<Alias>dev.purchasing.ucla.edu</Alias>
</Site>
<Site id="2098125309" name="staffdev.purchasing.ucla.edu">
<Alias>staffdev.purchasing.ucla.edu</Alias>
</Site>
</ISAPI>
</Implementation>

But this does not solve my problem; since it is not what I am trying to
do. Anyhow, in my scenario the 'ISAPI' segment of Shibboleth2.xml will
look something like this:

<ISAPI normalizeRequest="true">
<Site id="1" name="default">
<Alias>jobs.customer1.com</Alias>
<Alias>careers.customer2.com</Alias>
<Alias>employment.customer3.com</Alias>
</Site>
</ISAPI>

Assuming that 'default' is the single site listing in ISS and each of
the listed aliases are individual customer sites.

If this is correct; then how would my 'RequestMapper' segment look;
since I do not have names for individual Aliases? Please advise.

Thanks,
Sohail

-----Original Message-----
From: Scott Cantor [mailto:[hidden email]]
Sent: Thursday, January 22, 2009 11:57 AM
To: [hidden email]
Subject: RE: [Shib-Users] Single site Id hosting multiple SPs

Sohail Bashadi wrote on 2009-01-22:
> All customer test sites have a single external IP Address; so we only
> have one entry in IIS and we use host headers to load the appropriate
> content for each customer. Since the Shibboleth Daemon needs a unique
> site Id for each protected resource in Shibboleth2.xml;

That's incorrect. The Shibboleth Daemon is also irrelevant, it doesn't
even
know about the web sites.

The SP relies on Site ID -> hostname mappings to canonicalize the
hostname.
If you want a single site to support multiple hostnames, you'll have to
use
the <Alias> element inside the <Site> to add the additional hostnames
you
want.

That will authorize clients to use different hostnames and preserve them
for
mapping purposes. Of course, nothing in such a setup prevents a client
from
sending any hostname it wants. As long as you're not trying to create
access
or security rules based on that, you're fine. Using it to default to the
right IdP is perfectly reasonable.

Essentially, your two scenarios are the same. From the SP's point of
view,
you could lump every single customer into one SP and one default
application
with a bunch of different endpoints for each host. Within the
RequestMap,
putting an "entityID" property in the Host will route them to the right
IdP.

The only difference in the two situations is how the Site/Host mappings
are
done. In one case it might be a bunch of Sites and in the other one Site
and
a bunch of Aliases.

Now, if you want things to be complex, you can make it much harder by
creating different SP entityIDs for each host, but if it's one app
serving
the same basic service, I really wouldn't do that.

-- Scott



Reply | Threaded
Open this post in threaded view
|

RE: Single site Id hosting multiple SPs

Cantor, Scott E.
Sohail Bashadi wrote on 2009-01-23:
> Thanks! For the response; I think I mostly understand what is being
> suggested here. I am not clear on how to implement this; the only thing
> that I saw close to an example is the following:

That's pretty much it, yes. Just with a lot more Aliases presumably.

> But this does not solve my problem; since it is not what I am trying to
> do.

It is, or you didn't describe it accurately.

 Anyhow, in my scenario the 'ISAPI' segment of Shibboleth2.xml will
> look something like this:
>
> <ISAPI normalizeRequest="true"> <Site id="1" name="default">
> <Alias>jobs.customer1.com</Alias> <Alias>careers.customer2.com</Alias>
> <Alias>employment.customer3.com</Alias> </Site> </ISAPI>
>
> Assuming that 'default' is the single site listing in ISS and each of
> the listed aliases are individual customer sites.

No, name="default" implies you have a hostname of default. One of the names
has to be the default hostname, and that goes in the Site. The rest are in
the aliases, yes.

> If this is correct; then how would my 'RequestMapper' segment look;
> since I do not have names for individual Aliases? Please advise.

If you want this to work, your map has to list every alias as a Host because
that's what they are, vhosts.

-- Scott


Reply | Threaded
Open this post in threaded view
|

RE: Single site Id hosting multiple SPs

Sohail Bashadi
I have run into another issue with setting up Aliases. Each of my alias
sites needs to connect to a different IdP and I define this in my
RequestMapper, but unfortunately all the sites are being redirected to
the single IdP that is being referred to in the first Alias? It is as if
the information in the RequestMapper is being ignored completely. Is
there additional setup actions that I need to perform in order to get
this process working?

Any pointers are greatly appreciated!

Thanks,
Sohail
-----Original Message-----
From: Scott Cantor [mailto:[hidden email]]
Sent: Friday, January 23, 2009 12:15 PM
To: [hidden email]
Subject: RE: [Shib-Users] Single site Id hosting multiple SPs

Sohail Bashadi wrote on 2009-01-23:
> Thanks! For the response; I think I mostly understand what is being
> suggested here. I am not clear on how to implement this; the only
thing
> that I saw close to an example is the following:

That's pretty much it, yes. Just with a lot more Aliases presumably.

> But this does not solve my problem; since it is not what I am trying
to
> do.

It is, or you didn't describe it accurately.

 Anyhow, in my scenario the 'ISAPI' segment of Shibboleth2.xml will
> look something like this:
>
> <ISAPI normalizeRequest="true"> <Site id="1" name="default">
> <Alias>jobs.customer1.com</Alias> <Alias>careers.customer2.com</Alias>
> <Alias>employment.customer3.com</Alias> </Site> </ISAPI>
>
> Assuming that 'default' is the single site listing in ISS and each of
> the listed aliases are individual customer sites.

No, name="default" implies you have a hostname of default. One of the
names
has to be the default hostname, and that goes in the Site. The rest are
in
the aliases, yes.

> If this is correct; then how would my 'RequestMapper' segment look;
> since I do not have names for individual Aliases? Please advise.

If you want this to work, your map has to list every alias as a Host
because
that's what they are, vhosts.

-- Scott



Reply | Threaded
Open this post in threaded view
|

RE: Single site Id hosting multiple SPs

Cantor, Scott E.
Sohail Bashadi wrote on 2009-06-09:
> I have run into another issue with setting up Aliases. Each of my alias
> sites needs to connect to a different IdP and I define this in my
> RequestMapper, but unfortunately all the sites are being redirected to
> the single IdP that is being referred to in the first Alias? It is as if
> the information in the RequestMapper is being ignored completely. Is
> there additional setup actions that I need to perform in order to get
> this process working?

This thread is 5 months old, so I have no idea what you're asking about, but
if you want to hard wire an IdP to use based on a vhost, you can stick an
entityID property for it inside the <Host> in the request map to control
what the SessionInitiator will use when it runs automatically for those
requests.

That's a shorthand for defining a SessionInitiator per vhost and using
requireSessionWith instead of just requireSession; same thing, but a lot
more XML.

-- Scott


Reply | Threaded
Open this post in threaded view
|

Handling different AttributeValue Scope from same IdP

Sohail Bashadi
In reply to this post by Sohail Bashadi
Hi,

I have run into an issue where an IdP has different 'AttributeValue
Scope' values for different accounts, like '[hidden email]', '
[hidden email]', ' [hidden email]' etc. Currently, the
customer has provided us an account in the 'guest.abc.edu' sub-domain
and we are trying to authenticate using the 'eppn' attribute, the
authentication is successful, but the shibboleth daemon fails to forward
the 'eppn' attribute to my application. We have other customers who have
all users in one domain and their 'eppn' attribute is successfully
passed to our application. How can I update my SP configuration to allow
'sub-domains' to be authenticated while ensuring that customers with a
single domain don't run into any issues? I have a strong feeling that I
need to make some changes in my 'attribute-policy.xml' and
'attribute-map.xml', but don't know what these changes should be.

Any pointers are greatly appreciated.

Thanks!
Sohail

Reply | Threaded
Open this post in threaded view
|

RE: Handling different AttributeValue Scope from same IdP

Cantor, Scott E.
Sohail Bashadi wrote on 2009-06-18:
> How can I update my SP configuration to allow
> 'sub-domains' to be authenticated while ensuring that customers with a
> single domain don't run into any issues? I have a strong feeling that I
> need to make some changes in my 'attribute-policy.xml' and
> 'attribute-map.xml', but don't know what these changes should be.

I can't tell from your question whether or not this is a scenario involving
InCommon. Within the federation (and within most federations), it's part of
the IdP's metadata and the registration processes to establish the "scopes"
that are necessary/desired. It's technically possible to represent
*.domain.edu as legal, but I don't know if InCommon has ever done that.

It's certainly possible to directly authorize any scope you want to, but
it's obviously preferable to most SPs to delegate that to the federation.

There's a shared rule that applies to all scoped attributes and has an AND
functor around a pair of rules, one of which is the
saml:AttributeScopeMatchesShibMDScope functor that does the metadata scope
check. You can change that Rule into an OR that wraps the metadata functor
rule and an additional AND that itself wraps a rule for the AttributeIssuer
and a Scope Regex.

Something in this neighborhood:

    <afp:PermitValueRule id="ScopingRules" xsi:type="AND">
        <Rule xsi:type="NOT">
            <Rule xsi:type="AttributeValueRegex" regex="@"/>
        </Rule>
        <Rule xsi:type="OR">
           <Rule xsi:type="saml:AttributeScopeMatchesShibMDScope"
                xmlns:saml="urn:mace:shibboleth:2.0:afp:mf:saml"/>
           <Rule xsi:type="AND">
               <Rule xsi:type="basic:AttributeIssuerString"
                        value="SPentityIDhere"/>
               <Rule xsi:type="basic:AttributeScopeRegex"
                        regex=".+\.domain\.edu$"/>
           </Rule>
        </Rule>
    </afp:PermitValueRule>

Get the idea?

-- Scott


Reply | Threaded
Open this post in threaded view
|

RE: Handling different AttributeValue Scope from same IdP

Sohail Bashadi
Scott,

I get the basic idea of what is being done here. This an issue involving
InCommon, one question though about the snippet you suggested below:

 <afp:PermitValueRule id="ScopingRules" xsi:type="AND">
        <Rule xsi:type="NOT">
            <Rule xsi:type="AttributeValueRegex" regex="@"/>
        </Rule>
        <Rule xsi:type="OR">
           <Rule xsi:type="saml:AttributeScopeMatchesShibMDScope"
                xmlns:saml="urn:mace:shibboleth:2.0:afp:mf:saml"/>
           <Rule xsi:type="AND">
               <Rule xsi:type="basic:AttributeIssuerString"
                        value="SPentityIDhere"/>
               <Rule xsi:type="basic:AttributeScopeRegex"
                        regex=".+\.domain\.edu$"/>
           </Rule>
        </Rule>
    </afp:PermitValueRule>
 
Shouldn't the value in this Rule <Rule
xsi:type="basic:AttributeIssuerString" value="SPentityIDhere"/> be
"IdPentityID", instead of the SPentityID? Please let me know if I am
mis-understanding something.

Thanks,
Sohail
-----Original Message-----
From: Scott Cantor [mailto:[hidden email]]
Sent: Thursday, June 18, 2009 10:50 PM
To: [hidden email]
Subject: RE: [Shib-Users] Handling different AttributeValue Scope from
same IdP

Sohail Bashadi wrote on 2009-06-18:
> How can I update my SP configuration to allow
> 'sub-domains' to be authenticated while ensuring that customers with a
> single domain don't run into any issues? I have a strong feeling that
I
> need to make some changes in my 'attribute-policy.xml' and
> 'attribute-map.xml', but don't know what these changes should be.

I can't tell from your question whether or not this is a scenario
involving
InCommon. Within the federation (and within most federations), it's part
of
the IdP's metadata and the registration processes to establish the
"scopes"
that are necessary/desired. It's technically possible to represent
*.domain.edu as legal, but I don't know if InCommon has ever done that.

It's certainly possible to directly authorize any scope you want to, but
it's obviously preferable to most SPs to delegate that to the
federation.

There's a shared rule that applies to all scoped attributes and has an
AND
functor around a pair of rules, one of which is the
saml:AttributeScopeMatchesShibMDScope functor that does the metadata
scope
check. You can change that Rule into an OR that wraps the metadata
functor
rule and an additional AND that itself wraps a rule for the
AttributeIssuer
and a Scope Regex.

Something in this neighborhood:

    <afp:PermitValueRule id="ScopingRules" xsi:type="AND">
        <Rule xsi:type="NOT">
            <Rule xsi:type="AttributeValueRegex" regex="@"/>
        </Rule>
        <Rule xsi:type="OR">
           <Rule xsi:type="saml:AttributeScopeMatchesShibMDScope"
                xmlns:saml="urn:mace:shibboleth:2.0:afp:mf:saml"/>
           <Rule xsi:type="AND">
               <Rule xsi:type="basic:AttributeIssuerString"
                        value="SPentityIDhere"/>
               <Rule xsi:type="basic:AttributeScopeRegex"
                        regex=".+\.domain\.edu$"/>
           </Rule>
        </Rule>
    </afp:PermitValueRule>

Get the idea?

-- Scott



Reply | Threaded
Open this post in threaded view
|

RE: Handling different AttributeValue Scope from same IdP

Cantor, Scott E.
Sohail Bashadi wrote on 2009-06-19:
> Shouldn't the value in this Rule <Rule
> xsi:type="basic:AttributeIssuerString" value="SPentityIDhere"/> be
> "IdPentityID", instead of the SPentityID? Please let me know if I am
> mis-understanding something.

Yes, you're correct.
 
-- Scott


Reply | Threaded
Open this post in threaded view
|

RE: Handling different AttributeValue Scope from same IdP

Sohail Bashadi
In reply to this post by Sohail Bashadi
FYI,

This snippet is not working, I restarted the Shibboleth Daemon and the
webserver and am still not getting the 'eppn' attribute passed forward.
I tried with both 'SPentityID' and the 'IdPentityID' in the Rule.

Thanks!
Sohail

-----Original Message-----
From: Sohail Bashadi
Sent: Friday, June 19, 2009 10:46 AM
To: [hidden email]
Subject: RE: [Shib-Users] Handling different AttributeValue Scope from
same IdP

Scott,

I get the basic idea of what is being done here. This an issue involving
InCommon, one question though about the snippet you suggested below:

 <afp:PermitValueRule id="ScopingRules" xsi:type="AND">
        <Rule xsi:type="NOT">
            <Rule xsi:type="AttributeValueRegex" regex="@"/>
        </Rule>
        <Rule xsi:type="OR">
           <Rule xsi:type="saml:AttributeScopeMatchesShibMDScope"
                xmlns:saml="urn:mace:shibboleth:2.0:afp:mf:saml"/>
           <Rule xsi:type="AND">
               <Rule xsi:type="basic:AttributeIssuerString"
                        value="SPentityIDhere"/>
               <Rule xsi:type="basic:AttributeScopeRegex"
                        regex=".+\.domain\.edu$"/>
           </Rule>
        </Rule>
    </afp:PermitValueRule>
 
Shouldn't the value in this Rule <Rule
xsi:type="basic:AttributeIssuerString" value="SPentityIDhere"/> be
"IdPentityID", instead of the SPentityID? Please let me know if I am
mis-understanding something.

Thanks,
Sohail
-----Original Message-----
From: Scott Cantor [mailto:[hidden email]]
Sent: Thursday, June 18, 2009 10:50 PM
To: [hidden email]
Subject: RE: [Shib-Users] Handling different AttributeValue Scope from
same IdP

Sohail Bashadi wrote on 2009-06-18:
> How can I update my SP configuration to allow
> 'sub-domains' to be authenticated while ensuring that customers with a
> single domain don't run into any issues? I have a strong feeling that
I
> need to make some changes in my 'attribute-policy.xml' and
> 'attribute-map.xml', but don't know what these changes should be.

I can't tell from your question whether or not this is a scenario
involving
InCommon. Within the federation (and within most federations), it's part
of
the IdP's metadata and the registration processes to establish the
"scopes"
that are necessary/desired. It's technically possible to represent
*.domain.edu as legal, but I don't know if InCommon has ever done that.

It's certainly possible to directly authorize any scope you want to, but
it's obviously preferable to most SPs to delegate that to the
federation.

There's a shared rule that applies to all scoped attributes and has an
AND
functor around a pair of rules, one of which is the
saml:AttributeScopeMatchesShibMDScope functor that does the metadata
scope
check. You can change that Rule into an OR that wraps the metadata
functor
rule and an additional AND that itself wraps a rule for the
AttributeIssuer
and a Scope Regex.

Something in this neighborhood:

    <afp:PermitValueRule id="ScopingRules" xsi:type="AND">
        <Rule xsi:type="NOT">
            <Rule xsi:type="AttributeValueRegex" regex="@"/>
        </Rule>
        <Rule xsi:type="OR">
           <Rule xsi:type="saml:AttributeScopeMatchesShibMDScope"
                xmlns:saml="urn:mace:shibboleth:2.0:afp:mf:saml"/>
           <Rule xsi:type="AND">
               <Rule xsi:type="basic:AttributeIssuerString"
                        value="SPentityIDhere"/>
               <Rule xsi:type="basic:AttributeScopeRegex"
                        regex=".+\.domain\.edu$"/>
           </Rule>
        </Rule>
    </afp:PermitValueRule>

Get the idea?

-- Scott




Reply | Threaded
Open this post in threaded view
|

RE: Handling different AttributeValue Scope from same IdP

Cantor, Scott E.
Sohail Bashadi wrote on 2009-06-19:
> FYI,
>
> This snippet is not working, I restarted the Shibboleth Daemon and the
> webserver and am still not getting the 'eppn' attribute passed forward.
> I tried with both 'SPentityID' and the 'IdPentityID' in the Rule.

I can't say that any specific example will or won't work, just that the
concept is workable.

It's not terribly easy to tell which piece is rejecting something, the
logging isn't adequate.

-- Scott


Reply | Threaded
Open this post in threaded view
|

RE: Handling different AttributeValue Scope from same IdP

Sohail Bashadi
I cranked up the logging and here is the log from my shibd.log:

2009-06-19 11:12:12 DEBUG Shibboleth.Listener [1]: dispatching message
(UNR_Test::getHeaders::Application)
2009-06-19 11:12:12 DEBUG Shibboleth.Listener [1]: dispatching message
(UNR_Test/Login::run::Shib1SI)
2009-06-19 11:12:29 DEBUG Shibboleth.Listener [1]: dispatching message
(UNR_Test/SAML/POST)
2009-06-19 11:12:29 DEBUG OpenSAML.MessageDecoder.SAML1POST [1]:
validating input
2009-06-19 11:12:29 DEBUG OpenSAML.MessageDecoder.SAML1POST [1]: decoded
SAML response:
<Response xmlns="urn:oasis:names:tc:SAML:1.0:protocol"
xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"
xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
IssueInstant="2009-06-19T16:12:29.480Z" MajorVersion="1"
MinorVersion="1"
Recipient="https://test47.peopleadmin.com/Shibboleth.sso/SAML/POST"
ResponseID="_799eaa39a9145bf949c71a2a8057c565"><ds:Signature
xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:CanonicalizationMethod
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"></ds:Canonicalizatio
nMethod>
<ds:SignatureMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"></ds:SignatureMet
hod>
<ds:Reference URI="#_799eaa39a9145bf949c71a2a8057c565">
<ds:Transforms>
<ds:Transform
Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"></ds:T
ransform>
<ds:Transform
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"><ec:InclusiveNamespa
ces xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#" PrefixList="code
ds kind rw saml samlp typens #default xsd
xsi"></ec:InclusiveNamespaces></ds:Transform>
</ds:Transforms>
<ds:DigestMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"></ds:DigestMethod>
<ds:DigestValue>yiTrCJXx8GKXjCuwqlJeDtkm/FI=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>
        <!-- Signature Here -->
</ds:SignatureValue>
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>
        <!-- Cert HERE -->
</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo></ds:Signature><Status><StatusCode
Value="samlp:Success"></StatusCode></Status><Assertion
xmlns="urn:oasis:names:tc:SAML:1.0:assertion"
AssertionID="_d5878d7b606c02d076a7bae5a9cc467b"
IssueInstant="2009-06-19T16:12:29.479Z"
Issuer="urn:mace:incommon:unr.edu" MajorVersion="1"
MinorVersion="1"><Conditions NotBefore="2009-06-19T16:12:29.479Z"
NotOnOrAfter="2009-06-19T16:17:29.479Z"><AudienceRestrictionCondition><A
udience>https://emp219.peopleadmin.com/shibboleth</Audience></AudienceRe
strictionCondition></Conditions><AuthenticationStatement
AuthenticationInstant="2009-06-19T16:12:29.479Z"
AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:unspecified"><Subje
ct><NameIdentifier Format="urn:mace:shibboleth:1.0:nameIdentifier"
NameQualifier="urn:mace:incommon:unr.edu">_1bc85e14ccfa3e6e3c1714a63e81f
3a5</NameIdentifier><SubjectConfirmation><ConfirmationMethod>urn:oasis:n
ames:tc:SAML:1.0:cm:bearer</ConfirmationMethod></SubjectConfirmation></S
ubject><SubjectLocality
IPAddress="66.45.71.6"></SubjectLocality></AuthenticationStatement></Ass
ertion></Response>
2009-06-19 11:12:29 DEBUG OpenSAML.MessageDecoder.SAML1 [1]: extracting
issuer from SAML 1.x Response
2009-06-19 11:12:29 DEBUG OpenSAML.MessageDecoder.SAML1 [1]: response
from (urn:mace:incommon:unr.edu)
2009-06-19 11:12:29 DEBUG OpenSAML.MessageDecoder.SAML1 [1]: searching
metadata for response issuer...
2009-06-19 11:12:29 DEBUG OpenSAML.SecurityPolicyRule.MessageFlow [1]:
evaluating message flow policy (replay checking on, expiration 60)
2009-06-19 11:12:29 DEBUG XMLTooling.StorageService [1]: inserted record
(_799eaa39a9145bf949c71a2a8057c565) in context (MessageFlow)
2009-06-19 11:12:29 DEBUG OpenSAML.SecurityPolicyRule.XMLSigning [1]:
validating signature profile
2009-06-19 11:12:29 DEBUG XMLTooling.TrustEngine.ExplicitKey [1]:
attempting to validate signature with the peer's credentials
2009-06-19 11:12:29 DEBUG XMLTooling.TrustEngine.ExplicitKey [1]:
signature validated with credential
2009-06-19 11:12:29 DEBUG OpenSAML.SecurityPolicyRule.XMLSigning [1]:
signature verified against message issuer
2009-06-19 11:12:29 DEBUG Shibboleth.SSO.SAML1 [1]: processing message
against SAML 1.x SSO profile
2009-06-19 11:12:29 DEBUG Shibboleth.SSO.SAML1 [1]: extracting issuer
from SAML 1.x assertion
2009-06-19 11:12:29 DEBUG OpenSAML.SecurityPolicyRule.MessageFlow [1]:
evaluating message flow policy (replay checking on, expiration 60)
2009-06-19 11:12:29 DEBUG XMLTooling.StorageService [1]: inserted record
(_d5878d7b606c02d076a7bae5a9cc467b) in context (MessageFlow)
2009-06-19 11:12:29 DEBUG Shibboleth.SSO.SAML1 [1]: SSO profile
processing completed successfully
2009-06-19 11:12:29 DEBUG Shibboleth.SSO.SAML1 [1]: extracting pushed
attributes...
2009-06-19 11:12:29 DEBUG Shibboleth.AttributeExtractor.XML [1]:
skipping unmapped NameIdentifier with format
(urn:mace:shibboleth:1.0:nameIdentifier)
2009-06-19 11:12:29 DEBUG Shibboleth.SSO.SAML1 [1]: resolving
attributes...
2009-06-19 11:12:29 DEBUG Shibboleth.AttributeResolver.Query [1]:
attempting SAML 1.x attribute query
2009-06-19 11:12:29 DEBUG XMLTooling.SOAPTransport.CURL [1]: getting
connection handle to https://aa.unr.edu/shibboleth-idp/AA
2009-06-19 11:12:29 DEBUG XMLTooling.SOAPTransport.CURL [1]: nothing
free in pool, returning new connection handle
2009-06-19 11:12:29 DEBUG Shibboleth.SOAPClient [1]: prepping SOAP
transport for use by application (UNR_Test)
2009-06-19 11:12:32 DEBUG XMLTooling.SOAPClient [1]: marshalled
envelope:
<S:Envelope
xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"><S:Body><samlp:Reque
st xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol"
IssueInstant="2009-06-19T16:12:32Z" MajorVersion="1" MinorVersion="1"
RequestID="_f78a729c292035e69b58fdc5cd3eb5c6"><samlp:AttributeQuery
Resource="https://emp219.peopleadmin.com/shibboleth"><saml:Subject
xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"><saml:NameIdentifier
Format="urn:mace:shibboleth:1.0:nameIdentifier"
NameQualifier="urn:mace:incommon:unr.edu">_1bc85e14ccfa3e6e3c1714a63e81f
3a5</saml:NameIdentifier></saml:Subject></samlp:AttributeQuery></samlp:R
equest></S:Body></S:Envelope>
2009-06-19 11:12:32 DEBUG XMLTooling.SOAPTransport.CURL [1]: sending
SOAP message to https://aa.unr.edu/shibboleth-idp/AA
2009-06-19 11:12:36 DEBUG XMLTooling.SOAPTransport.CURL [1]: invoking
custom X.509 verify callback
2009-06-19 11:12:36 DEBUG XMLTooling.TrustEngine.ExplicitKey [1]:
attempting to match credentials from peer with end-entity certificate
2009-06-19 11:12:36 DEBUG XMLTooling.TrustEngine.ExplicitKey [1]:
end-entity certificate matches peer RSA key information
2009-06-19 11:12:36 DEBUG XMLTooling.SOAPClient [1]: received XML:
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><soap:Body><Respon
se xmlns="urn:oasis:names:tc:SAML:1.0:protocol"
InResponseTo="_f78a729c292035e69b58fdc5cd3eb5c6"
IssueInstant="2009-06-19T16:12:36.801Z" MajorVersion="1"
MinorVersion="1" ResponseID="_c08223707672a40599be4b9d0604630c"
xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"
xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol"><Status><StatusCode
Value="samlp:Success"/></Status><Assertion
xmlns="urn:oasis:names:tc:SAML:1.0:assertion"
AssertionID="_88906a5082281c7ccbcddf533170ea13"
IssueInstant="2009-06-19T16:12:36.800Z"
Issuer="urn:mace:incommon:unr.edu" MajorVersion="1"
MinorVersion="1"><Conditions NotBefore="2009-06-19T16:12:36.800Z"
NotOnOrAfter="2009-06-19T16:42:36.800Z"><AudienceRestrictionCondition><A
udience>https://emp219.peopleadmin.com/shibboleth</Audience></AudienceRe
strictionCondition></Conditions><AttributeStatement><Subject><NameIdenti
fier Format="urn:mace:shibboleth:1.0:nameIdentifier"
NameQualifier="urn:mace:incommon:unr.edu">_1bc85e14ccfa3e6e3c1714a63e81f
3a5</NameIdentifier></Subject><Attribute
AttributeName="urn:mace:dir:attribute-def:eduPersonPrincipalName"
AttributeNamespace="urn:mace:shibboleth:1.0:attributeNamespace:uri"><Att
ributeValue
Scope="guest.unr.edu">tvaldez</AttributeValue></Attribute></AttributeSta
tement></Assertion></Response></soap:Body></soap:Envelope>
2009-06-19 11:12:36 DEBUG OpenSAML.SecurityPolicyRule.MessageFlow [1]:
evaluating message flow policy (replay checking on, expiration 60)
2009-06-19 11:12:36 DEBUG OpenSAML.SecurityPolicyRule.MessageFlow [1]:
evaluating message flow policy (replay checking on, expiration 60)
2009-06-19 11:12:36 DEBUG XMLTooling.StorageService [1]: inserted record
(_c08223707672a40599be4b9d0604630c) in context (MessageFlow)
2009-06-19 11:12:36 DEBUG OpenSAML.SecurityPolicyRule.MessageFlow [1]:
evaluating message flow policy (replay checking on, expiration 60)
2009-06-19 11:12:36 DEBUG XMLTooling.StorageService [1]: inserted record
(_88906a5082281c7ccbcddf533170ea13) in context (MessageFlow)
2009-06-19 11:12:36 DEBUG Shibboleth.AttributeDecoder.Scoped [1]:
decoding ScopedAttribute (eppn) from SAML 1 Attribute
(urn:mace:dir:attribute-def:eduPersonPrincipalName) with 1 value(s)
2009-06-19 11:12:37 DEBUG Shibboleth.AttributeFilter [1]: filtering 1
attribute(s) from (urn:mace:incommon:unr.edu)
2009-06-19 11:12:37 DEBUG Shibboleth.AttributeFilter [1]: applying
filtering rule(s) for attribute (eppn) from (urn:mace:incommon:unr.edu)
2009-06-19 11:12:37 WARN Shibboleth.AttributeFilter [1]: removed value
at position (0) of attribute (eppn) from (urn:mace:incommon:unr.edu)
2009-06-19 11:12:37 WARN Shibboleth.AttributeFilter [1]: no values left,
removing attribute (eppn) from (urn:mace:incommon:unr.edu)
2009-06-19 11:12:37 DEBUG Shibboleth.SessionCache [1]: creating new
session
2009-06-19 11:12:37 DEBUG Shibboleth.SessionCache [1]: storing new
session...
2009-06-19 11:12:37 DEBUG XMLTooling.StorageService [1]: inserted record
(session) in context (_91c0caa02f4fb1d81d2aba17f22e9fa0)
2009-06-19 11:12:37 DEBUG XMLTooling.StorageService [1]: inserted record
(_1bc85e14ccfa3e6e3c1714a63e81f3a5) in context (NameID)
2009-06-19 11:12:37 DEBUG XMLTooling.StorageService [1]: inserted record
(_d5878d7b606c02d076a7bae5a9cc467b) in context
(_91c0caa02f4fb1d81d2aba17f22e9fa0)
2009-06-19 11:12:37 DEBUG XMLTooling.StorageService [1]: inserted record
(_88906a5082281c7ccbcddf533170ea13) in context
(_91c0caa02f4fb1d81d2aba17f22e9fa0)
2009-06-19 11:12:37 INFO Shibboleth.SessionCache [1]: new session
created: ID (_91c0caa02f4fb1d81d2aba17f22e9fa0) IdP
(urn:mace:incommon:unr.edu)
Protocol(urn:oasis:names:tc:SAML:1.1:protocol) Address (192.168.2.116)
2009-06-19 11:12:37 DEBUG Shibboleth.SSO.SAML1 [1]: ACS returning via
redirect to: https://test47.peopleadmin.com/secure/index.php
2009-06-19 11:12:37 DEBUG Shibboleth.Listener [1]: dispatching message
(find::StorageService::SessionCache)
2009-06-19 11:12:37 DEBUG XMLTooling.StorageService [1]: updated
expiration of valid records in context
(_91c0caa02f4fb1d81d2aba17f22e9fa0)

Also, I am capturing all the attributes being returned by the IdP via a
PHP page, here is the output of that:

Array ( [ALLUSERSPROFILE] => C:\Documents and Settings\All Users
[CLASSPATH] => C:\Program
Files\Jmeter\jakarta-jmeter-2.0.0\bin\ApacheJMeter.jar, C:\Program
Files\Jmeter\jakarta-jmeter-2.0.0\lib\ext\ApacheJmeter_core.jarC:\Progra
m Files\Jmeter\jakarta-jmeter-2.0.0\lib\jorphan.jar, C:\Program
Files\Jmeter\jakarta-jmeter-2.0.0\lib\logkit-1.0.1.jar
[CommonProgramFiles] => C:\Program Files\Common Files [COMPUTERNAME] =>
MARS [ComSpec] => C:\WINNT\system32\cmd.exe [CONTENT_LENGTH] => 0
[GATEWAY_INTERFACE] => CGI/1.1 [HTTPS] => on [HTTPS_KEYSIZE] => 128
[HTTPS_SECRETKEYSIZE] => 1024 [HTTPS_SERVER_ISSUER] => C=ZA, S=Western
Cape, L=Cape Town, O=Thawte Consulting cc, OU=Certification Services
Division, CN=Thawte Premium Server CA, E=[hidden email]
[HTTPS_SERVER_SUBJECT] => C=US, S=Texas, L=Austin, O="PeopleAdmin,
Inc.", OU=PeopleAdmin, CN=*.peopleadmin.com [HTTP_ACCEPT] => image/gif,
image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash,
application/vnd.ms-excel, application/vnd.ms-powerpoint,
application/msword, application/x-ms-application, application/x-ms-xbap,
application/vnd.ms-xpsdocument, application/xaml+xml, */*
[HTTP_ACCEPT_LANGUAGE] => en-us [HTTP_CONNECTION] => Keep-Alive
[HTTP_HOST] => test47.peopleadmin.com [HTTP_REFERER] =>
https://idp.unr.edu/shibboleth-idp/SSO?shire=https%3A%2F%2Ftest47.people
admin.com%2FShibboleth.sso%2FSAML%2FPOST&time=1245427932&target=cookie%3
A29002348&providerId=https%3A%2F%2Femp219.peopleadmin.com%2Fshibboleth&t
icket=ST-24-KcRHDY3I6VVR75fPReQY [HTTP_USER_AGENT] => Mozilla/4.0
(compatible; MSIE 7.0; Windows NT 5.1; InfoPath.2; .NET CLR 2.0.50727;
.NET CLR 3.0.4506.2152; .NET CLR 3.5.30729) [HTTP_COOKIE] =>
__utma=238775809.540187274.1243194393.1244830227.1245186916.3;
__utmz=238775809.1243194393.1.1.utmccn=(direct)|utmcsr=(direct)|utmcmd=(
none);
_shibsession_554e525f5465737468747470733a2f2f656d703231392e70656f706c656
1646d696e2e636f6d2f73686962626f6c657468=_91c0caa02f4fb1d81d2aba17f22e9fa
0 [HTTP_UA_CPU] => x86 [HTTP_ACCEPT_ENCODING] => gzip, deflate
[HTTP_CACHE_CONTROL] => no-cache [HTTP_SHIBSPOOFCHECK] => <!-- Random
String Here --> [HTTP_SHIB_APPLICATION_ID] => UNR_Test
[HTTP_SHIB_SESSION_ID] => _91c0caa02f4fb1d81d2aba17f22e9fa0
[HTTP_SHIB_IDENTITY_PROVIDER] => urn:mace:incommon:unr.edu
[HTTP_SHIB_AUTHENTICATION_INSTANT] => 2009-06-19T16:12:29.479Z
[HTTP_SHIB_AUTHENTICATION_METHOD] =>
urn:oasis:names:tc:SAML:1.0:am:unspecified
[HTTP_SHIB_AUTHNCONTEXT_CLASS] =>
urn:oasis:names:tc:SAML:1.0:am:unspecified [INSTANCE_ID] => 6
[LOCAL_ADDR] => 192.168.2.14 [NUMBER_OF_PROCESSORS] => 1 [Os2LibPath] =>
C:\WINNT\system32\os2\dll; [OS] => Windows_NT [Path] =>
C:\PHP\;C:\Perl\bin\;C:\WINNT\system32;C:\WINNT;C:\WINNT\System32\Wbem;C
:\PROGRA~1\ULTRAE~1;C:\Program Files\Microsoft SQL
Server\80\Tools\BINN;E:\jprofiler3\bin\windows;C:\Program
Files\MySQL\MySQL Server 4.1\bin;C:\Program Files\Support
Tools\;C:\opt\shibboleth-sp\bin\;C:\opt\shibboleth-sp\lib\ [PATHEXT] =>
.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH [PATH_TRANSLATED] =>
C:\www\secure\index.php [PHPRC] => C:\PHP\ [PROCESSOR_ARCHITECTURE] =>
x86 [PROCESSOR_IDENTIFIER] => x86 Family 6 Model 8 Stepping 6,
GenuineIntel [PROCESSOR_LEVEL] => 6 [PROCESSOR_REVISION] => 0806
[ProgramFiles] => C:\Program Files [REMOTE_ADDR] => 192.168.2.116
[REMOTE_HOST] => 192.168.2.116 [REQUEST_METHOD] => GET [SCRIPT_NAME] =>
/secure/index.php [SERVER_NAME] => test47.peopleadmin.com [SERVER_PORT]
=> 443 [SERVER_PORT_SECURE] => 1 [SERVER_PROTOCOL] => HTTP/1.1
[SERVER_SOFTWARE] => Microsoft-IIS/5.0 [SHIBSP_PREFIX] =>
C:/opt/shibboleth-sp [SHIBSP_SCHEMAS] =>
C:\opt\shibboleth-sp\share\xml\shibboleth\catalog.xml;C:\opt\shibboleth-
sp\share\xml\xmltooling\catalog.xml;C:\opt\shibboleth-sp\share\xml\opens
aml\saml20-catalog.xml;C:\opt\shibboleth-sp\share\xml\opensaml\saml11-ca
talog.xml [SystemDrive] => C: [SystemRoot] => C:\WINNT [TEMP] =>
C:\WINNT\TEMP [TMP] => C:\WINNT\TEMP [USERPROFILE] => C:\Documents and
Settings\Default User [windir] => C:\WINNT [ORIG_PATH_INFO] =>
/secure/index.php [SCRIPT_FILENAME] => C:\www\secure\index.php
[PHP_SELF] => /secure/index.php [REQUEST_TIME] => 1245427957 )

Does any of this help debug this issue? As you can see the
AttributeValue Scope is set to 'Scope="guest.unr.edu"' for user
'tvaldez', which is the test account.

Thanks,
Sohail

-----Original Message-----
From: Scott Cantor [mailto:[hidden email]]
Sent: Friday, June 19, 2009 10:59 AM
To: [hidden email]
Subject: RE: [Shib-Users] Handling different AttributeValue Scope from
same IdP

Sohail Bashadi wrote on 2009-06-19:
> FYI,
>
> This snippet is not working, I restarted the Shibboleth Daemon and the
> webserver and am still not getting the 'eppn' attribute passed
forward.
> I tried with both 'SPentityID' and the 'IdPentityID' in the Rule.

I can't say that any specific example will or won't work, just that the
concept is workable.

It's not terribly easy to tell which piece is rejecting something, the
logging isn't adequate.

-- Scott



Reply | Threaded
Open this post in threaded view
|

RE: Handling different AttributeValue Scope from same IdP

Cantor, Scott E.
Sohail Bashadi wrote on 2009-06-19:
> Does any of this help debug this issue? As you can see the
> AttributeValue Scope is set to 'Scope="guest.unr.edu"' for user
> 'tvaldez', which is the test account.

No, it means nothing other than it's being filtered. As I said, the logging
is inadequate.

You can file a bug, but my only step would be to attempt to reproduce
something similar and if it works for me, I'll close it. If you think it's
something to do with the policy used, you'd have to debug into it or add
logging, unfortunately.

Filtering is a very rarely used feature. My advice here, frankly, is just
work around the issue for now by turning off the policy and then ask
InCommon to get this resolved with the IdP. It just isn't practical for
every SP to go around creating custom scope rules.

-- Scott


Reply | Threaded
Open this post in threaded view
|

RE: Handling different AttributeValue Scope from same IdP

Sohail Bashadi

So, how can I "turn off" this policy and then ask InCommon to get this
resolved with the IdP? Are there any security concerns with this
approach?

Thanks,
Sohail
-----Original Message-----
From: Scott Cantor [mailto:[hidden email]]
Sent: Friday, June 19, 2009 9:14 PM
To: [hidden email]
Subject: RE: [Shib-Users] Handling different AttributeValue Scope from
same IdP

Sohail Bashadi wrote on 2009-06-19:
> Does any of this help debug this issue? As you can see the
> AttributeValue Scope is set to 'Scope="guest.unr.edu"' for user
> 'tvaldez', which is the test account.

No, it means nothing other than it's being filtered. As I said, the
logging
is inadequate.

You can file a bug, but my only step would be to attempt to reproduce
something similar and if it works for me, I'll close it. If you think
it's
something to do with the policy used, you'd have to debug into it or add
logging, unfortunately.

Filtering is a very rarely used feature. My advice here, frankly, is
just
work around the issue for now by turning off the policy and then ask
InCommon to get this resolved with the IdP. It just isn't practical for
every SP to go around creating custom scope rules.

-- Scott



Reply | Threaded
Open this post in threaded view
|

RE: Handling different AttributeValue Scope from same IdP

Cantor, Scott E.
Sohail Bashadi wrote on 2009-06-22:
> So, how can I "turn off" this policy and then ask InCommon to get this
> resolved with the IdP?

It's the IdP's responsibility to deal with their metadata and get that fixed
(or stop using subdomains). Turning off the policy just requires commenting
out the function that's doing the metadata scope enforcement.

> Are there any security concerns with this approach?

You're trusting IdPs not to send a value scoped to somebody else.
 
-- Scott


Reply | Threaded
Open this post in threaded view
|

Re: Handling different AttributeValue Scope from same IdP

Cantor, Scott E.
In reply to this post by Sohail Bashadi
FWIW, I just tested *exactly* the policy I suggested you could use with my
IdP after altering the scope values in the metadata, and it worked fine.

If it didn't work for you, your regular expression was probably faulty for
the particular value(s) you wanted to accept.

-- Scott