Post saml reponse from one shib idp to other shib idp

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

Post saml reponse from one shib idp to other shib idp

dalipcse91
Hi Team,
I got stranded on one test cases, we are using shibboleth as identity
provider with custom service provider. This service provider can be
authenticated by more than one idp. Right now we have two shibboleth idp.
one is primary idp and second idp is as trust provider in first idp. and
first idp added as trust provider in custom service provider. On primary
IDP's login page, when user enter username, based on username's domain we
create a authn request to particular idp. idp authenticates user and post a
saml response to primary idp's SAML2/POST/SSO location. In response we are
able to see attributes and other details as well. my problem is that primary
idp did not post this saml response(getting from secondary idp) to custom
sp's consuming url. i am getting below error message.
<http://shibboleth.1660669.n2.nabble.com/file/t398613/Capture12.jpg>



--
Sent from: http://shibboleth.1660669.n2.nabble.com/Shibboleth-Users-f1660767.html
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Post saml reponse from one shib idp to other shib idp

Peter Schober
* dalipcse91 <[hidden email]> [2018-05-15 10:50]:
> I got stranded on one test cases, we are using shibboleth as identity
> provider with custom service provider. This service provider can be
> authenticated by more than one idp. Right now we have two shibboleth idp.
> one is primary idp and second idp is as trust provider in first idp.

Can you explain in terms of the Shibboleth configuration changes
you've made what that means, specifically, "adding an IDP as a trust
provider to another IDP"?

Did you add a SAML SP to your "primary" SAML IDP and configure the
"primary" IDP to get data about the subject from this SAML SP (which
in turn gets it from other IDPs)?

> and first idp added as trust provider in custom service provider.

I guess that just means the "primary" IDP is added as a SAML IDP to
your SAML SP, as usual.

> On primary IDP's login page, when user enter username, based on
> username's domain we create a authn request to particular idp.

OK, that's the unusual part. Normally you'd simply expose the
individual IDPs a subject may have an association with to the SP.

(Another way people have dealt with this is not using SAML between the
"primary" IDP and the other IDPs, but LDAP, so it's only the primary
IDP asking for your credentials and validating them using a "backend"
protocol.)

So you've turned your "primaty IDP" into a SAML proxy, somehow. I
guess it's your task then to make sure that proxy behaves correctly.

> idp authenticates user and post a saml response to primary idp's
> SAML2/POST/SSO location.

The IDP does not provide an endpoint where it recieves SAML responses
from other IDPs.

> In response we are able to see attributes and other details as
> well.

"In response" means you're looking at the SAML response sent by the
other IDP on-the-wire? Your "primary" Shibboleth IDP does not contain
SAML SP code that would process such a response.

> my problem is that primary idp did not post this saml
> response(getting from secondary idp) to custom sp's consuming url.

The Shibboleth IDP is not a SAML SP, and it also does not come with
proxy functionality out of the box. So the IDP will not process the
response sent to it from another IDP, and it also won't re-sign and
re-post it to another SAML SP, magically.

> i am getting below error message.
> <http://shibboleth.1660669.n2.nabble.com/file/t398613/Capture12.jpg>

The error message is in your log files, not in the browser or in the
SAML protocol messages.

-peter
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Post saml reponse from one shib idp to other shib idp

dalipcse91
For Point : Can you explain in terms of the Shibboleth configuration changes
for adding an IDP as a trust
provider to another IDP" ?

*Step 1*: Download secondary IDP metadata from HTTP://{}/idp/shibboleth
*Step 2*: Add this downloaded metadata reference in local IDP's
metadata-providers file at location {idp.home}/conf/metadata-providers.xml
as below:
  <MetadataProvider id="LocalMetadata1"
xsi:type="FilesystemMetadataProvider" metadataFile="C:\Program Files
(x86)\Shibboleth\IdP\metadata\mp2012-idp-metadata.xml"/>


*Step 3*: In step 2 we have done with adding secondary IDP as trust provider
in primary IDP.
*Step 4* : Add primary IDP as relying party in secondary IDP using below
process. Metadata of primary IDP to behave as relying party as below:
<http://shibboleth.1660669.n2.nabble.com/file/t398613/Capture13.jpg>
*Step 5*: XML file from step4 added as reference in secondary IDP's
Metadata-providers.xml.
*Step 6*: So from step 4, 5 we can say that secondary IDP have primary IDP's
metadata and primary idp have secondary idp's metadata.

*Step7 *: Added custom sp metadata in primary IDP's metadata-providers.xml
file. as below:
<http://shibboleth.1660669.n2.nabble.com/file/t398613/Capture14.jpg>
*Step 8*: All relying party configuration remains  unchanged.

*Step 9*: Secondary IDP's metadata file :

  <?xml version="1.0" encoding="UTF-8"?>

<EntityDescriptor  xmlns="urn:oasis:names:tc:SAML:2.0:metadata"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns:shibmd="urn:mace:shibboleth:metadata:1.0"
xmlns:xml="http://www.w3.org/XML/1998/namespace"
xmlns:mdui="urn:oasis:names:tc:SAML:metadata:ui"
entityID="http://mp2012r2-roja2.sotiindia.edu:8080/idp/shibboleth">
    <IDPSSODescriptor
protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol
urn:oasis:names:tc:SAML:1.1:protocol urn:mace:shibboleth:1.0">
        <Extensions>
            <shibmd:Scope regexp="false">example.org</shibmd:Scope>
        </Extensions>
        <KeyDescriptor use="signing">
            <ds:KeyInfo>
                    <ds:X509Data>
                       
<ds:X509Certificate>--certificate--</ds:X509Certificate>
                    </ds:X509Data>
            </ds:KeyInfo>
        </KeyDescriptor>
        <KeyDescriptor use="signing">
            <ds:KeyInfo>
                    <ds:X509Data>
                       
<ds:X509Certificate>--certificate--</ds:X509Certificate>
                    </ds:X509Data>
            </ds:KeyInfo>
        </KeyDescriptor>
        <KeyDescriptor use="encryption">
            <ds:KeyInfo>
                    <ds:X509Data>
                       
<ds:X509Certificate>--certificate--</ds:X509Certificate>
                    </ds:X509Data>
            </ds:KeyInfo>
        </KeyDescriptor>
        <ArtifactResolutionService
Binding="urn:oasis:names:tc:SAML:1.0:bindings:SOAP-binding"
Location="http://mp2012r2-roja2.sotiindia.edu:8443/idp/profile/SAML1/SOAP/ArtifactResolution"
index="1"/>
        <ArtifactResolutionService
Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP"
Location="http://mp2012r2-roja2.sotiindia.edu:8443/idp/profile/SAML2/SOAP/ArtifactResolution"
index="2"/>    

        <SingleSignOnService
Binding="urn:mace:shibboleth:1.0:profiles:AuthnRequest"
Location="http://mp2012r2-roja2.sotiindia.edu:8080/idp/profile/Shibboleth/SSO"/>
        <SingleSignOnService
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
Location="http://mp2012r2-roja2.sotiindia.edu:8080/idp/profile/SAML2/POST/SSO"/>
        <SingleSignOnService
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign"
Location="http://mp2012r2-roja2.sotiindia.edu:8080/idp/profile/SAML2/POST-SimpleSign/SSO"/>
        <SingleSignOnService
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"
Location="http://mp2012r2-roja2.sotiindia.edu:8080/idp/profile/SAML2/Redirect/SSO"/>

    </IDPSSODescriptor>
    <AttributeAuthorityDescriptor
protocolSupportEnumeration="urn:oasis:names:tc:SAML:1.1:protocol">

        <Extensions>
            <shibmd:Scope regexp="false">example.org</shibmd:Scope>
        </Extensions>
        <KeyDescriptor use="signing">
            <ds:KeyInfo>
                    <ds:X509Data>
                       
<ds:X509Certificate>--certificate--</ds:X509Certificate>
                    </ds:X509Data>
            </ds:KeyInfo>
        </KeyDescriptor>
        <KeyDescriptor use="signing">
            <ds:KeyInfo>                    <ds:X509Data>
                       
<ds:X509Certificate>--certificate--</ds:X509Certificate>
                    </ds:X509Data>
            </ds:KeyInfo>
        </KeyDescriptor>
        <KeyDescriptor use="encryption">
            <ds:KeyInfo>
                    <ds:X509Data>
                       
<ds:X509Certificate>--certificate--</ds:X509Certificate>
                    </ds:X509Data>
            </ds:KeyInfo>

        </KeyDescriptor>

        <AttributeService
Binding="urn:oasis:names:tc:SAML:1.0:bindings:SOAP-binding"
Location="http://mp2012r2-roja2.sotiindia.edu:8443/idp/profile/SAML1/SOAP/AttributeQuery"/>
       
       

    </AttributeAuthorityDescriptor>

</EntityDescriptor>

Step 10: Primary IDP metadata for adding this as RP in secondary IDP:

<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
ID="_8523ab8065a69338d5006c34310dc8d2c0179ebb"
entityID="http://ind107.corp.soti.net:8080/idp/shibboleth">

  <md:Extensions xmlns:alg="urn:oasis:names:tc:SAML:metadata:algsupport">
    <alg:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha512"/>
    <alg:DigestMethod
Algorithm="http://www.w3.org/2001/04/xmldsig-more#sha384"/>
    <alg:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
    <alg:DigestMethod
Algorithm="http://www.w3.org/2001/04/xmldsig-more#sha224"/>
    <alg:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
    <alg:SigningMethod
Algorithm="http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha512"/>
    <alg:SigningMethod
Algorithm="http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha384"/>
    <alg:SigningMethod
Algorithm="http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha256"/>
    <alg:SigningMethod
Algorithm="http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha224"/>
    <alg:SigningMethod
Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha512"/>
    <alg:SigningMethod
Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha384"/>
    <alg:SigningMethod
Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
    <alg:SigningMethod
Algorithm="http://www.w3.org/2009/xmldsig11#dsa-sha256"/>
    <alg:SigningMethod
Algorithm="http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha1"/>
    <alg:SigningMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
    <alg:SigningMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1"/>
  </md:Extensions>

  <md:SPSSODescriptor
protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol
urn:oasis:names:tc:SAML:1.1:protocol urn:oasis:names:tc:SAML:1.0:protocol">
    <md:Extensions>
     
     
     
    </md:Extensions>
    <md:KeyDescriptor>
      <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        <ds:KeyName>ind107.corp.soti.net</ds:KeyName>
        <ds:X509Data>
          <ds:X509SubjectName>CN=ind107.corp.soti.net</ds:X509SubjectName>
          <ds:X509Certificate>-- certificate --</ds:X509Certificate>
        </ds:X509Data>
      </ds:KeyInfo>
   
    </md:KeyDescriptor>

    <md:AssertionConsumerService
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
Location="http://ind107.corp.soti.net:8080/idp/profile/SAML2/POST/SSO"
index="0" />
       

  </md:SPSSODescriptor>

</md:EntityDescriptor>

*Step 11*: Normal metadata of primary IDP :
<?xml version="1.0" encoding="UTF-8"?>

<EntityDescriptor  xmlns="urn:oasis:names:tc:SAML:2.0:metadata"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns:shibmd="urn:mace:shibboleth:metadata:1.0"
xmlns:xml="http://www.w3.org/XML/1998/namespace"
xmlns:mdui="urn:oasis:names:tc:SAML:metadata:ui"
entityID="http://ind107.corp.soti.net:8080/idp/shibboleth">

    <IDPSSODescriptor
protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol
urn:oasis:names:tc:SAML:1.1:protocol urn:mace:shibboleth:1.0">

        <Extensions>
            <shibmd:Scope regexp="false">example.org</shibmd:Scope>

        </Extensions>

        <KeyDescriptor use="signing">
            <ds:KeyInfo>
                    <ds:X509Data>
                       
<ds:X509Certificate>--certificate--</ds:X509Certificate>
                    </ds:X509Data>
            </ds:KeyInfo>

        </KeyDescriptor>
        <KeyDescriptor use="signing">
            <ds:KeyInfo>
                    <ds:X509Data>
                        <ds:X509Certificate>--certificate--
</ds:X509Certificate>
                    </ds:X509Data>
            </ds:KeyInfo>

        </KeyDescriptor>
        <KeyDescriptor use="encryption">
            <ds:KeyInfo>
                    <ds:X509Data>
                        <ds:X509Certificate>--certificate--
</ds:X509Certificate>
                    </ds:X509Data>
            </ds:KeyInfo>

        </KeyDescriptor>

        <ArtifactResolutionService
Binding="urn:oasis:names:tc:SAML:1.0:bindings:SOAP-binding"
Location="http://ind107.corp.soti.net:8443/idp/profile/SAML1/SOAP/ArtifactResolution"
index="1"/>
        <ArtifactResolutionService
Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP"
Location="http://ind107.corp.soti.net:8443/idp/profile/SAML2/SOAP/ArtifactResolution"
index="2"/>

 

        <SingleSignOnService
Binding="urn:mace:shibboleth:1.0:profiles:AuthnRequest"
Location="http://ind107.corp.soti.net:8080/idp/profile/Shibboleth/SSO" />
        <SingleSignOnService
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
Location="http://ind107.corp.soti.net:8080/idp/profile/SAML2/POST/SSO"  />
        <SingleSignOnService
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign"
Location="http://ind107.corp.soti.net:8080/idp/profile/SAML2/POST-SimpleSign/SSO"
/>
        <SingleSignOnService
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"
Location="http://ind107.corp.soti.net:8080/idp/profile/SAML2/Redirect/SSO"
/>
               

    </IDPSSODescriptor>


    <AttributeAuthorityDescriptor
protocolSupportEnumeration="urn:oasis:names:tc:SAML:1.1:protocol">

        <Extensions>
            <shibmd:Scope regexp="false">example.org</shibmd:Scope>
        </Extensions>

        <KeyDescriptor use="signing">
            <ds:KeyInfo>
                    <ds:X509Data>
                       
<ds:X509Certificate>--certificate--</ds:X509Certificate>
                    </ds:X509Data>
            </ds:KeyInfo>

        </KeyDescriptor>
        <KeyDescriptor use="signing">
            <ds:KeyInfo>
                    <ds:X509Data>
                       
<ds:X509Certificate>--certificate--</ds:X509Certificate>
                    </ds:X509Data>
            </ds:KeyInfo>

        </KeyDescriptor>
        <KeyDescriptor use="encryption">
            <ds:KeyInfo>
                    <ds:X509Data>
                       
<ds:X509Certificate>--certificate--</ds:X509Certificate>
                    </ds:X509Data>
            </ds:KeyInfo>

        </KeyDescriptor>

        <AttributeService
Binding="urn:oasis:names:tc:SAML:1.0:bindings:SOAP-binding"
Location="http://ind107.corp.soti.net:8443/idp/profile/SAML1/SOAP/AttributeQuery"
index="0"/>
       
       

    </AttributeAuthorityDescriptor>

</EntityDescriptor>

Step 15: Now user open custom app and click on login button. On login
primary IDP's login page comes, here user enter user name and we have handle
a on-blur event on user name field. On blur event we call an api to get
details of IDP, which will authenticate this user based on domain name for
entered email.
*Step 16*: After getting IDP details from back end we create a saml authn
request seems as below:

http://mp2012r2-roja2.sotiindia.edu:8080/idp/profile/SAML2/Redirect/SSO?SAMLRequest=
<samlp:AuthnRequest ID="_f8a16c8b-845f-4342-a37c-7f643da05a46" Version="2.0"
IssueInstant="2018-05-15T11:01:28Z"
ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
AssertionConsumerServiceURL="http://ind107.corp.soti.net:8080/idp/profile/SAML2/POST/SSO"
Destination="http://mp2012r2-roja2.sotiindia.edu:8080/idp/profile/SAML2/Redirect/SSO"
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"><saml:Issuer
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">http://localhost:8000</saml:Issuer><samlp:NameIDPolicy
AllowCreate="true" /></samlp:AuthnRequest>

*Here http://ind107.corp.soti.net:8080/idp/profile/SAML2/POST/SSO is primary
IDP.
and http://mp2012r2-roja2.sotiindia.edu:8080/idp/profile/SAML2/Redirect/SSO
secondary IDP.*


So My requirement is that" if user enter this email then user should
authenticate from A IDP else B IDP."
How can we achieve this ?

For u this is my flow diagram :
  <http://shibboleth.1660669.n2.nabble.com/file/t398613/Capture15.jpg>

Please suggest me how can i achieve this. is there is any other options to
achieve this ?
Looking for your valuable response.











--
Sent from: http://shibboleth.1660669.n2.nabble.com/Shibboleth-Users-f1660767.html
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Post saml reponse from one shib idp to other shib idp

Peter Schober
* dalipcse91 <[hidden email]> [2018-05-15 14:49]:

> > Can you explain in terms of the Shibboleth configuration changes
> > for adding an IDP as a trust provider to another IDP" ?
>
> *Step 1*: Download secondary IDP metadata from HTTP://{}/idp/shibboleth
> *Step 2*: Add this downloaded metadata reference in local IDP's
> metadata-providers file at location {idp.home}/conf/metadata-providers.xml
> as below:
>   <MetadataProvider id="LocalMetadata1"
> xsi:type="FilesystemMetadataProvider" metadataFile="C:\Program Files
> (x86)\Shibboleth\IdP\metadata\mp2012-idp-metadata.xml"/>

OK. Adding IDP metadata to an IDP is pointless, It will achieve
nothing. Incidently, that's also the summary of everything you've been
doing here, I think.

> Step 10: Primary IDP metadata for adding this as RP in secondary IDP:

You can't add an IDP "as an SP". Either it's an IDP or an SP or it has
both roles (or not of them).

The Shibboleth IDP is not a SAML SP. Period.
Simply creating SAML Metadata with an SPSSODescriptor role and
configuring the IDP's SSO endpoint (where it recieves REQUESTS) as an
SP's AssertionConsumerService URL (where an SP recieces RESPONSES)
will not magically make the IDP an SP.

> *Step 16*: After getting IDP details from back end we create a saml authn request seems as below:

What you can do is create a SAML authn request with the real SP as the
Issuer (and with the ACS URL pointing to the real SP) and send it to
the actual IDP. That's what any normal SAML SP would do itself anyway.
Then the subject authenticates at the real IDP and gets sent to the
real SP, without involving the SAML proxy (what you continue calling
your "primary IDP", when it's not an IDP at all, AFAICT).

The only alternative to the above is creating an actual SAML proxy in
place of what you call the "primary IDP". From what I've seen so far
you don't have one, you seem to think simply misconfiguring metadata
at will will turn the Shibboleth IDP into a SAML SP or SAML proxy.

> So My requirement is that" if user enter this email then user should
> authenticate from A IDP else B IDP."  How can we achieve this ?

I have not paying close attention to the many lines of metadata you
sent, but that requirement seems new to me. Maybe I've missed it in
your previous post.

Either way, that sounds like a requirement for a SAML IDP Discovery
Service (allowing to pick an IDP based on entering personal data, such
as an email address, which I personally think is a stupid idea), not
for a SAML proxy.

-peter
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Post saml reponse from one shib idp to other shib idp

David Huebner
On 15.05.2018 18:11, Peter Schober wrote:
So My requirement is that" if user enter this email then user should
authenticate from A IDP else B IDP."  How can we achieve this ?
I have not paying close attention to the many lines of metadata you
sent, but that requirement seems new to me. Maybe I've missed it in
your previous post.

Either way, that sounds like a requirement for a SAML IDP Discovery
Service (allowing to pick an IDP based on entering personal data, such
as an email address, which I personally think is a stupid idea), not
for a SAML proxy.
The only possible advantage of doing that inside the SAML proxy is user friendliness. That way the user does not have to enter his credentials (i.e. email) twice.
Basically [...]@example.org triggers an internal loginflow and requests the password for that account straight away, while every other hostname gets sent away to some external IdP, leveraging a "SAML proxy loginflow".
I think I've seen that done in simplesamlphp at some point where asking the user for information as few times as possible was the major concern.

Anyways, you will need a SAML proxy for that functionality regardless and Shibboleth is not one out of the box.

- David

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]

smime.p7s (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Post saml reponse from one shib idp to other shib idp

Peter Schober
* David Huebner <[hidden email]> [2018-05-16 15:37]:
> The only possible advantage of doing that inside the SAML proxy is
> user friendliness. That way the user does not have to enter his
> credentials (i.e.  email) twice.

I thought asking for email was only done to get the subject to type
the DNS domain of their IDP (i.e., it's only about phrasing this in a
way that the subject should be able to understand, not about the
user-identifying part and certainly not about entering the password in
more than one place?

I.e., the purpose of this process seems to be to replace
typeahead-style UI components (to interactively determine the IDP
based on some identifying information, could be display name, parts of
the entityID, etc.) with "type your DNS domain and hit enter", and
then either failing that with an error ("Cannot find the IDP") or
start the SAML2 login flow to the IDP, hopefully the one the subject
intended.
Only there would I enter my identifying information ("credentials").

-peter
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Post saml reponse from one shib idp to other shib idp

David Huebner
On 16.05.2018 16:06, Peter Schober wrote:

> * David Huebner <[hidden email]> [2018-05-16 15:37]:
>> The only possible advantage of doing that inside the SAML proxy is
>> user friendliness. That way the user does not have to enter his
>> credentials (i.e.  email) twice.
> I thought asking for email was only done to get the subject to type
> the DNS domain of their IDP (i.e., it's only about phrasing this in a
> way that the subject should be able to understand, not about the
> user-identifying part and certainly not about entering the password in
> more than one place?
>
> I.e., the purpose of this process seems to be to replace
> typeahead-style UI components (to interactively determine the IDP
> based on some identifying information, could be display name, parts of
> the entityID, etc.) with "type your DNS domain and hit enter", and
> then either failing that with an error ("Cannot find the IDP") or
> start the SAML2 login flow to the IDP, hopefully the one the subject
> intended.
> Only there would I enter my identifying information ("credentials").
>
> -peter
 From what I understood the purpose is not only to identify the IdP to
be used for authentication (discovery service), but actually
authenticate the user straight away (and by that I mean ask the user for
his password) if certain conditions are met (i.e. the DNS domain of the
email address entered matches some preconfigured string).

Let's assume that preconfigured string is example.org. The "primary IdP"
would then go ahead and present the user with a form "Please enter your
email address".

Case 1: User enters [hidden email]. Primary IdP says "Oh,
example.org is my domain and I can authenticate that user against my AD"
and asks for password.

Case 2: User enters [hidden email]. Primary IdP says "I
don't recognize that domain" and sends the user off to the "Secondary
IdP" via its SP component (or then presents the user with a discovery
service).

In the end the idea is, that *most* users are in fact Case 1 and should
not be annoyed with the extra discovery service before getting to the
"Primary IdP" (neglecting permanent cookies for now).

- David


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]

smime.p7s (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Post saml reponse from one shib idp to other shib idp

Peter Schober
* David Huebner <[hidden email]> [2018-05-16 16:36]:

> From what I understood the purpose is not only to identify the IdP to be
> used for authentication (discovery service), but actually authenticate the
> user straight away (and by that I mean ask the user for his password) if
> certain conditions are met (i.e. the DNS domain of the email address entered
> matches some preconfigured string).
>
> Let's assume that preconfigured string is example.org. The "primary IdP"
> would then go ahead and present the user with a form "Please enter your
> email address".
>
> Case 1: User enters [hidden email]. Primary IdP says "Oh, example.org is
> my domain and I can authenticate that user against my AD" and asks for
> password.
>
> Case 2: User enters [hidden email]. Primary IdP says "I don't
> recognize that domain" and sends the user off to the "Secondary IdP" via its
> SP component (or then presents the user with a discovery service).

OK, modulo "its SP component" you're free to implement this in the
current IDP.  Instead of the "SP component" the "primary IDP" can just
mint an authn request from the real SP itself, no proxy required.

(If the SP publishes metadata that says auth requests are signed then
it should either stop doing that or provide a RequestInitiator element
so the "primary IDP" can trigger a signed auth request from the SP,
targeting the actually desirable IDP.)

-peter
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]