[Shib-Users] IdP Login URL

[yusufali]

I have successfully setup the IdP system and tested it out using TestShib
with both RemoteUser and LDAP Authentication.

I am connecting the IdP to a test WebEx site, and having trouble configuring
the login URL. When I specify the provided login.jsp or
/idp/Authn/UserPassword, I get the error message about direct access to the
page not allowed. When I specified /idp/profile/shibboleth/SSO, I get errors
about providedId not being present, and when I add that to the URL, it says
shire is not present. Currently I have pointed it to
/idp/profile/SAML2/Redirect/SSO, and I get the following error message:

14:45:47.045 - INFO [Shibboleth-Access:73] -
20110309T204547Z|144.45.113.162|testidm-auth2.dot.state.tx.us:443|/profile/SAML2/Redirect/SSO|
1582 14:45:47.046 - DEBUG
[edu.internet2.middleware.shibboleth.idp.profile.IdPProfileHandlerManager:85]
- shibboleth.HandlerManager: Looking up profile handler for request
path: /SAML2/Redirect/SSO
1583 14:45:47.050 - DEBUG
[edu.internet2.middleware.shibboleth.idp.profile.IdPProfileHandlerManager:96]
- shibboleth.HandlerManager: Located pro file handler of the
following type for the request path:
edu.internet2.middleware.shibboleth.idp.profile.saml2.SSOProfileHandler
1584 14:45:47.051 - DEBUG
[edu.internet2.middleware.shibboleth.idp.util.HttpServletHelper:326] -
Looking up LoginContext with key d7df8b9d-f49f-
4af5-b01e-4edee2249be2 from StorageService parition: loginContexts
1585 14:45:47.052 - DEBUG
[edu.internet2.middleware.shibboleth.idp.util.HttpServletHelper:332] -
Retrieved LoginContext with key d7df8b9d-f49f-4 af5-b01e-4edee2249be2
from StorageService parition: loginContexts
1586 14:45:47.052 - DEBUG
[edu.internet2.middleware.shibboleth.idp.profile.saml2.SSOProfileHandler:163]
- Incoming request contained a login con text but principal was not
authenticated, processing as first leg of request
1587 14:45:47.052 - DEBUG
[edu.internet2.middleware.shibboleth.idp.profile.saml2.SSOProfileHandler:301]
- Decoding message with decoder binding
'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect'
1588 14:45:47.055 - WARN
[edu.internet2.middleware.shibboleth.idp.profile.saml2.SSOProfileHandler:333]
- Error decoding authentication request m essage
1589 org.opensaml.ws.message.decoder.MessageDecodingException: No
SAMLRequest or SAMLResponse query path parameter, invalid SAML 2 HTTP
Redirect message
1590 at
org.opensaml.saml2.binding.decoding.HTTPRedirectDeflateDecoder.doDecode(HTTPRedirectDeflateDecoder.java:97)
~[opensaml-2.4.1.jar :na]
1591 at
org.opensaml.ws.message.decoder.BaseMessageDecoder.decode(BaseMessageDecoder.java:75)
~[openws-1.4.1.jar:na]

Any help will be appreciated.
Thanks.

Hasnain

--
View this message in context: http://shibboleth.1660669.n2.nabble.com/IdP-Login-URL-tp6155498p6155498.html
Sent from the Shibboleth - Users mailing list archive at Nabble.com.

[Cantor, Scott E.]

> I am connecting the IdP to a test WebEx site, and having trouble configuring
> the login URL.

And what profiles and bindings exactly does WebEx support?

-- Scott

[yusufali]

From their docs:

The WebEx Federated Authentication Service (FAS) allows employees and
affiliates of a WebEx customer organization to authenticate with a WebEx
site using the SAML 1.1, 2.0 or WS-Federation 1.0 protocols.
The WebEx FAS accepts SAML assertions using the Browser/POST or “push” model
profile. The customer web site acts as the Identity Provider (IdP) and the
WebEx site acts as the Service Provider (SP) or Relying Party (RP).

IdP Initiated SSO
WebEx FAS supports IdP initiated SSO with the Browser/POST binding for SAML
1.1 and 2.0.
WebEx FAS also supports IdP-initiated SSO with the Browser/Artifact binding
for SAML 1.1 only.

Hasnain

--
View this message in context: http://shibboleth.1660669.n2.nabble.com/IdP-Login-URL-tp6155498p6155624.html

[Cantor, Scott E.]

> IdP Initiated SSO
> WebEx FAS supports IdP initiated SSO with the Browser/POST binding for
> SAML
> 1.1 and 2.0.
> WebEx FAS also supports IdP-initiated SSO with the Browser/Artifact binding
> for SAML 1.1 only.

Then you probably can't use SAML 2.0 without waiting for 2.3, and SAML 1.1 support would be doable via the legacy Shibboleth request protocol which you can find documentation on in the wiki. Don't guess at parameters, just read the old protocols/profiles document, it's very short.

-- Scott

[yusufali]

I don't understand completely. I thought the current version was SAML 2.0
compliant:
"Shibboleth 2.0 is built primarily on SAML 2.0 and includes a large number
..."

Can you please explain?
Thanks.

Hasnain

--
View this message in context: http://shibboleth.1660669.n2.nabble.com/IdP-Login-URL-tp6155498p6155760.html

[Cantor, Scott E.]

> I don't understand completely. I thought the current version was SAML 2.0
> compliant:
> "Shibboleth 2.0 is built primarily on SAML 2.0 and includes a large number
> ..."
>
> Can you please explain?

We don't (yet) support IdP-initiated SSO and my reading of your message suggests they don't support SP-initiated SSO. In other words, neither end is actually compliant.

-- Scott

[yusufali]

Ok, thanks.
Any idea when 2.3 will be ready for roll-out?

Hasnain

--
View this message in context: http://shibboleth.1660669.n2.nabble.com/IdP-Login-URL-tp6155498p6155811.html

[Cantor, Scott E.]

> Any idea when 2.3 will be ready for roll-out?

Aprilish, maybe. I already gave you a workaround in any case.

-- Scott

[Cantor, Scott E.]

> We don't (yet) support IdP-initiated SSO and my reading of your message
> suggests they don't support SP-initiated SSO. In other words, neither end is
> actually compliant.

I should have said "conformant". Compliance is a question of behavior within the scope of what's supported. We have never claimed conformance with any particular set of features, at least not generally. We're definitely not IdP or IdP-Lite conformant. And your SP in question is not conformant either.

-- Scott

[Christopher Bland]

Hasnain,

Is WebEx requiring you to use the federation protocol?  Our WebEx SSO config page allowed us to choose SAML 2.0 as our protocol of choice and SP Initiated as our SSO profile.  You should also be able to download their metadata from the SSO config page.  Although WebEx does not use Shibboleth, it is possible to use your IDP.

-Chris

[Cantor, Scott E.]

Ok, then it should work fine with a supported 2.0 binding endpoint and the problem would be deployment error of some sort.

-- Scott

-----Original Message-----
From: Christopher Bland <ch...@fdu.edu>
Sent: Wednesday, March 09, 2011 6:16 PM
To: shibbole...@internet2.edu <shibbole...@internet2.edu>
Subject: Re: [Shib-Users] RE: IdP Login URL

[yusufali]

No, I didn't realize they had support for SAML 2.0 with SP iniated SSO.
Can you please help with what is required to be entered in the SSO config
page:

AuthnRequest Signed (Yes/No)
Destination
Target page URL Parameter
WebEx SAML Issuer (SP ID)
Issuer for SAML (IdP ID)
Customer SSO Service Login URL

They have a feature to import the idp metadata, but it keeps complaining
that the Shibboleth IdP metadata file is not valid.

Thanks.
Hasnain

--
View this message in context: http://shibboleth.1660669.n2.nabble.com/IdP-Login-URL-tp6155498p6155987.html

[Christopher Bland]

Hasnain,

There are a few other out in the community that have gotten this to work hopefully they can fill any gaps I miss.

There's a link for " Site Certificate Manager".  I used this to upload the cert for my IDP.

Federation Protocol:  SAML 2.0

SSO Profile:  SP Initiated

NameID Format:  Unspecified

AuthnContextClassRef: urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport

Default WebEx Target page URL:  I left it blank you may want to change it after you get up and running

There's a link for "Import SAML Metadata".  I used that to upload my IDP's metadata

You have to check the "Single Logout" checkbox and provide a URL otherwise your users will not have a logout button.

AuthnRequest Signed (Yes/No)

I didn't have an option for AuthnRequest.  I believe it was specified in the WebEx metadata.

Destination
Target page URL Parameter

Left unchanged since I was not doing IDP initiated

WebEx SAML Issuer (SP ID)

http://www.webex.com

Issuer for SAML (IdP ID)

https://your_idp_url/idp/shibboleth

Customer SSO Service Login URL

https://your_idp_url/idp/profile/SAML2/Redirect/SSO

Hope this helps,

-Chris

[Cal Heldenbrand]

I have a small follow up question to this -- is IdP initiated SSO part of the SAML 2.0 specification?  Or is it just a convenience tacked on from SAML 1.1?

I've been searching through the SAML spec docs and haven't found anything...  I'm working with a vendor that is requiring me to do IdP initiated SSO.  So, if there's any voting tally for this in the upcoming shib 2.3, please chalk one up for me.  ;-)

Thanks,

--Cal

[Chad La Joie]

On Tue, Mar 15, 2011 at 10:30, Cal Heldenbrand <c...@fbsdata.com> wrote:
> I have a small follow up question to this -- is IdP initiated SSO part of
> the SAML 2.0 specification?  Or is it just a convenience tacked on from SAML
> 1.1?

Neither standard defines the mechanism by which the IdP is told to
initiate the SSO. Both standards however indicate that SPs need to
accept unsolicited authentication responses (which is what IdP
initiated SSO looks like from the SP's side). So, all we're doing for
2.3 is using the proprietary method we had in place for doing this
with SAML 1.1 with SAML 2.0.

--
Chad La Joie
www.itumi.biz
trusted identities, delivered

[Cantor, Scott E.]

> I have a small follow up question to this -- is IdP initiated SSO part of the
> SAML 2.0 specification? Or is it just a convenience tacked on from SAML 1.1?

Both SAML 1.1 and SAML 2.0 "require" IdP-initiated SSO for conformance. The problem is that the concept is nonsensical. IdPs are not self aware, so they don't initiate anything. If yours does, step away from the console and walk slowly out of your data center.

So there is a protocol somewhere to tell the IdP to send you to an SP. That protocol isn't defined in SAML, which means the IdP is allowed to provide any mechanism for that it wants to. The problem is that once you do that, you either end up duplicating what's already in SAML, or even worse, you could prevent the use of some SAML features, such as requiring a signed request, as in fact what we're doing will prevent.

The best answer is the extension I specified for third party requests, but supporting it properly is a great deal of policy work, and it doesn't satisfy the itch of people that want a simple unsigned redirect with parameters.

-- Scott

[Cal Heldenbrand]

So, the specification says the IdP should do this behavior, but has no standard definition of how it should be implemented?

Also, on signature requirements -- isn't that defined in the SP metadata?  So the SP and IdP could predefine these settings and not require them in each session handshake?

I'm guessing in the end, people just want to set up new relationships as quickly and easily as possible.  (Setting aside some security implications in favor of the business goals)  Just my two cents.

--Cal

[Cantor, Scott E.]

> So, the specification says the IdP should do this behavior, but has no
> standard definition of how it should be implemented?

Right.

> Also, on signature requirements -- isn't that defined in the SP metadata? So
> the SP and IdP could predefine these settings and not require them in each
> session handshake?

Policy is advertised in metadata, it's not enforced there. That's immaterial; the point is that if I say to require signed requests and then have to support SSO via a simple redirect that can't be signed, the policy's impossible to use. And inventing a new protocol that supports the full range of security options is just silly.

> I'm guessing in the end, people just want to set up new relationships as
> quickly and easily as possible. (Setting aside some security implications in
> favor of the business goals) Just my two cents.

Until it gets hacked, at which point it's the software's fault.

-- Scott

[yusufali]

Chris, thanks for the information. With a little more tweaking at my end, I
am now able to login by authenticating with our ldap.

WebEx has an Auto Account create feature. Required attributes are firstname,
lastname, uid, and email. I can see that idp is retrieving and releasing
those attributes, but in the source attribute name, i.e. givenName, sn,
commonName, and mail. Where do I specify attribute mappings?

Also, I cannot find the SAML assertion anywhere in the idp logs. And I only
get AuthnRequests in the HTTP headers when I look at the SAMLResponse. Are
the assertions stored anywhere on the idp side? If not, how can get to them?

Thanks.
Hasnain

--
View this message in context: http://shibboleth.1660669.n2.nabble.com/IdP-Login-URL-tp6155498p6182492.html