"Shibbolising" ASP .Net application(s)

Gilles Badouet badouetg at uni.coventry.ac.uk
Fri Jul 26 05:31:03 EDT 2013


>That generally means you will have a lot of trouble ripping out or routing
>around existing behavior.

Why? I note that I  don't have necessarily to associate the Shibboleth base authentication to the existing authentication system. I have nothing to do with the existing authentication box. I got the application library and what I have to do is to experiment the Shibboleth authentication system within another box and indepently on the existing authentication.

>Unless you explain what you're confused by, there's nothing else I can say.
I am confused by what scenario to follow because I havent seen in the related wiki page (https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPEnableApplication) which files and which elements to configure.I just know that I have to place the application in "secure" folder.

I also read that 'Request Headers' is the only integration mechanism supported by IIS/ ASP .Net applications and don't understand how  and where to apply it.

I would like  to know  what files and elements I should configure regarding  my environment (IIS)  or a link describing an ASP .NET integration example.



Kind regards





Gilles Rubens Badouet



________________________________________
From: users-bounces at shibboleth.net <users-bounces at shibboleth.net> on behalf of users-request at shibboleth.net <users-request at shibboleth.net>
Sent: 25 July 2013 01:35
To: users at shibboleth.net
Subject: users Digest, Vol 25, Issue 111

Send users mailing list submissions to
        users at shibboleth.net

To subscribe or unsubscribe via the World Wide Web, visit
        http://shibboleth.net/mailman/listinfo/users
or, via email, send a message with subject or body 'help' to
        users-request at shibboleth.net

You can reach the person managing the list at
        users-owner at shibboleth.net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of users digest..."


Today's Topics:

   1. Re: How to change relying-party.xml config location
      dynamically (Yaowen Tu)
   2. Re: "Shibbolising" ASP .Net  application(s) (Cantor, Scott)
   3. Multiple IDP Entity IDs with 1 IDP (bs_sunil)
   4. Re: Multiple IDP Entity IDs with 1 IDP (Cantor, Scott)
   5. Is IDP tied to specific spring version? (Zmuda, Matthew R)


----------------------------------------------------------------------

Message: 1
Date: Wed, 24 Jul 2013 13:55:09 -0700
From: Yaowen Tu <yaowen.tu at gmail.com>
Subject: Re: How to change relying-party.xml config location
        dynamically
To: Shib Users <users at shibboleth.net>
Message-ID:
        <CAE7YPDLBH0J1VZvm=y2g9=RsKntANokv9QHZ+6gnvQ9HBGv1uQ at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

Thanks Scott and Paul. I just got to build a simple plugin that does the
placeholder work. It is not that difficult actually.

Yaowen


On Tue, Jul 23, 2013 at 5:33 PM, Cantor, Scott <cantor.2 at osu.edu> wrote:

> On 7/23/13 8:21 PM, "Yaowen Tu" <yaowen.tu at gmail.com> wrote:
>
> >I hope it is better to change the source code directly, because most
> >likely it will be a generic place, once I change it, the same place
> >holder can be applied to any ConfigurationResource values that defined in
> >other places.
>
> No, I'm saying you need to write a plugin implementing a new type of
> ConfigurationResource, like any other Spring extension.
>
> You should not patch existing code to do this. That won't be maintainable,
> at least while 2.x is supported.
>
> And no, there is no place to do it. Every resource plugin type implements
> its own syntax and logic, there's no single place to change behavior, and
> it wouldn't even make sense since not all of them are file system paths
> anyway.
>
> >So can anyone give me some hint about where it is?
>
> I told you, the existing plugins for that interface are in the resource
> subpackage in shibboleth-common. Using those to create your own in a new
> extension jar should do what you need.
>
> I thought for some reason you had done some work on a custom login handler
> so were familiar with extensions. If you haven't written any extensions,
> then you're going to have to learn a lot to do that, I can't really do
> more than point to the wiki and the contributions people have made that
> implement plugins for other APIs.
>
> Please use the dev list for further questions about this.
>
> -- Scott
>
>
> --
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20130724/da4786ab/attachment-0001.html

------------------------------

Message: 2
Date: Wed, 24 Jul 2013 21:35:11 +0000
From: "Cantor, Scott" <cantor.2 at osu.edu>
Subject: Re: "Shibbolising" ASP .Net  application(s)
To: Shib Users <users at shibboleth.net>
Message-ID:
        <BA63CEAE152A7742B854C678D9491383AD12CC5F at CIO-KRC-D1MBX01.osuad.osu.edu>

Content-Type: text/plain; charset="us-ascii"

On 7/24/13 4:49 PM, "Gilles Badouet" <badouetg at uni.coventry.ac.uk> wrote:

>I have just acquired 3 ASP. Net applications and want now to test my
>implementation with one of
> the applications first, which already has an authentication system
>handled by SQL server 2008.

That generally means you will have a lot of trouble ripping out or routing
around existing behavior.

>  I plan afterward to test the implementation with all the 3
>applications.
>What is the good approach/scenarios to intergrating ASP .Net
>application(s)? I read the wiki docs, but still confused with where to
>start.

There is no such thing as "make a .NET app work". Every application is
different, apart from following various good and bad patterns of design
that are common. The integration depends entirely on the application and
how it works.

The only thing the SP does is what it's documented to do, and the wiki
describes integration patterns that are of general interest. The rest is
not something that can be turned into a recipe.

Unless you explain what you're confused by, there's nothing else I can say.

>On the other hand, I would like to know if there is any method to
>customize the login page, logout page...without requiring to update the
>installation of the IdP.

The IdP is in control of that, that's not up to the SP.

> Or How to update that installation while keeping unchanged the already
>configured metadata,
> IdP credentials and other files?

Updating it or rebuilding the warfile after changing something has no
impact on any of that.

-- Scott




------------------------------

Message: 3
Date: Wed, 24 Jul 2013 16:35:00 -0700 (PDT)
From: bs_sunil <bssunil74 at yahoo.com>
Subject: Multiple IDP Entity IDs with 1 IDP
To: users at shibboleth.net
Message-ID: <1374708900015-7588769.post at n2.nabble.com>
Content-Type: text/plain; charset=us-ascii

Hello

I have a third party IDP where I can create multiple SAML connectors. I am
using the latest Shibboleth SP for apache on the application side. I have
configured (that is request mapper, application override) in Shibboleth2.xml
to cater to 2 virtual hosts in apache. It is working fine for one app with
one IDP metadata (<MetadataProvider type="XML"
file="idpmetadata-app1.xml"/>). But for the other app how do I specify
another locally available IDP metadata file?
Most of the search in forumns I see are "Discovery/WAYF service" when it
comes to virtual hosts which I do not want to use since the IDP metadata are
locally available. The IDP is same but the entity id for each virtual host
app is different (which is why 2 metadata files) corresponding to 2 SAML
connectors in the IDP.

I do not mind using one entity for both virtual host but here is the issue.
Lets say the virtual hosts are https://testa.com and https://testb.com. When
the SAML request comes from https://testa.com, the SAML response is posted
to https://testa.com by the IDP since https://testa.com is configured as the
ACS url. But when the request comes from https://testb.com, there is an
infinite http redirection because IDP posts the response to
https://testa.com and not https://testb.com.

Thanks
Sunil



--
View this message in context: http://shibboleth.1660669.n2.nabble.com/Multiple-IDP-Entity-IDs-with-1-IDP-tp7588769.html
Sent from the Shibboleth - Users mailing list archive at Nabble.com.


------------------------------

Message: 4
Date: Thu, 25 Jul 2013 00:04:37 +0000
From: "Cantor, Scott" <cantor.2 at osu.edu>
Subject: Re: Multiple IDP Entity IDs with 1 IDP
To: Shib Users <users at shibboleth.net>
Message-ID:
        <BA63CEAE152A7742B854C678D9491383AD12CDB3 at CIO-KRC-D1MBX01.osuad.osu.edu>

Content-Type: text/plain; charset="us-ascii"

On 7/24/13 7:35 PM, "bs_sunil" <bssunil74 at yahoo.com> wrote:

>It is working fine for one app with
>one IDP metadata (<MetadataProvider type="XML"
>file="idpmetadata-app1.xml"/>). But for the other app how do I specify
>another locally available IDP metadata file?

I don't think you need an override, but the answer is, the same way.
Overrides contain whatever configuration elements you want to override. If
you want different metadata, give it different metadata.

>
>Most of the search in forumns I see are "Discovery/WAYF service" when it
>comes to virtual hosts which I do not want to use since the IDP metadata
>are
>locally available.

Discovery has nothing to do with getting metadata, it's about picking the
IdP to use. You don't need to use an override just to associate a vhost
with a specific IdP.

> The IDP is same but the entity id for each virtual host
>app is different (which is why 2 metadata files) corresponding to 2 SAML
>connectors in the IDP.

That doesn't make any sense. The IdP should be the same named entity
regardless.

>I do not mind using one entity for both virtual host but here is the
>issue.
>Lets say the virtual hosts are https://testa.com and https://testb.com.
>When
>the SAML request comes from https://testa.com, the SAML response is posted
>to https://testa.com by the IDP since https://testa.com is configured as
>the
>ACS url. But when the request comes from https://testb.com, there is an
>infinite http redirection because IDP posts the response to
>https://testa.com and not https://testb.com.

Then possibly your web server isn't configured correctly, or your IdP is
misconfigured or has incorrect metadata or isn't using it. You should
establish what the SP is asking the IdP to do first by tracing, and then
figure out which end is at fault.

The SP unless badly configured will always specify the URL to return to in
its requests. If the ACS URL in the request contains the wrong hostname,
then it sounds like your web server is not properly vhosting yet.

-- Scott




------------------------------

Message: 5
Date: Wed, 24 Jul 2013 20:35:03 -0400
From: "Zmuda, Matthew R" <Matthew.R.Zmuda at td.com>
Subject: Is IDP tied to specific spring version?
To: "users at shibboleth.net" <users at shibboleth.net>
Message-ID:
        <D8382768F64DA745B6A5CA29EF121E84EA865057 at EX7T2-SV12.TDBFG.COM>
Content-Type: text/plain; charset="iso-8859-1"

Hi all,

If I am using IDP version 2.3.3 (with spring 2.5.x) would there be issues upgrading to Spring 3.0.x?
I did upgrade of several Spring libraries to v3.0 and noticed that all attributes defined as Script attributes are no longer resolving.
No errors whatsoever logged they are just flat out ignored..

For example this is ignored:

      <resolver:AttributeDefinition xsi:type="Script" xmlns="urn:mace:shibboleth:2.0:resolver:ad" id="myID">
            <resolver:AttributeEncoder xsi:type="SAML2String" xmlns="urn:mace:shibboleth:2.0:attribute:encoder" name="myID" />

          <Script><![CDATA[
            // my scrip....
          ]]></Script>
      </resolver:AttributeDefinition>

However this continues to work:

      <resolver:AttributeDefinition id="principalName" xsi:type="ad:PrincipalName">
            <resolver:AttributeEncoder xsi:type="enc:SAML1StringNameIdentifier" nameFormat="urn:mace:shibboleth:1.0:nameIdentifier" />
            <resolver:AttributeEncoder xsi:type="enc:SAML2StringNameID" nameFormat="urn:oasis:names:tc:SAML:2.0:nameid-format:transient" />
            <resolver:AttributeEncoder xsi:type="enc:SAML2StringNameID" nameFormat="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent" />
      </resolver:AttributeDefinition>

NOTICE: Confidential message which may be privileged. Unauthorized use/disclosure prohibited. If received in error, please go to www.td.com/legal for instructions.
AVIS : Message confidentiel dont le contenu peut ?tre privil?gi?. Utilisation/divulgation interdites sans permission. Si re?u par erreur, pri?re d'aller au www.td.com/francais/avis_juridique pour des instructions.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20130724/e4916a67/attachment.html

------------------------------

--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net

End of users Digest, Vol 25, Issue 111
**************************************



More information about the users mailing list