[Shib-Users] Shibboleth IdP talking to WebLogic 10.3 SP via SAML 2.0

[Nick Newman]

Hi,

I have a Shibboleth IdP set up and am trying to get it to talk to a WebLogic 10.3 SP using SAML 2.0.  So my first question is, has anyone managed to do that?  (I have seen some discussions of success using SAML 1.1)

If nobody has a complete solution then perhaps I can get some help completing my own attempt...

I myself got quite close using SAML 2.0.  Everything seems to be fine until WebLogic receives the assertion from Shibboleth.  Here is a snippet from that assertion:

<saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" 

Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">https://bea383438.inl.gov/idp/shibboleth</saml2:Issuer>

But WebLogic says:

<[Security:096536]Invalid issuer format: urn:oasis:names:tc:SAML:2.0:nameid-format:entity.> 

which I do not understand since this seems to be completely according to spec.  Perhaps WebLogic would be happier if the Format attribute (or even the entire Issuer tag) were omitted, which I believe is also spec compliant.  Any idea how Shibboleth can be made to do that?

If there's no luck there either then I suppose I'll have to drop back to SAML 1.1   :-(

Thanks,

Nick Newman

[Chad La Joie]

No, short of changing the code, there is no way to change what the IdP
creates for the issuer. I would recommend, at least, submitting a bug
against WebLogic. Who knows if it'll ever get fixed, but at least there
is a chance this way.

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

[Nick Newman]

Thank you for the reply.  So it seems that I would be best off (for now) dropping back to SAML 1.1.  But now my newness to Shibboleth is causing me trouble.  I get one of the common errors, "No return endpoint available for relying party http://bea383438.inl.gov:7001/", but I am having a lot of trouble understanding why.

I found this (almost) step-by-step guide on how to do what I want:  http://tinyurl.com/37unn5l

Based on this and some more reading I made the following SP metadata by hand and referred to it from the relying-party.xml.  (In WebLogic my asserting party is ap_00001).

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

<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"

entityID="http://bea383438.inl.gov:7001/">

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

<NameIDFormat>urn:mace:shibboleth:1.0:nameIdentifier</NameIDFormat>

<AssertionConsumerService

Binding="urn:oasis:names:tc:SAML:1.0:profiles:browser-post" Location="http://bea383438.inl.gov:7001/samlacs/acs?APID=ap_00001"

index="1" isDefault="true" />

</md:SPSSODescriptor>

</md:EntityDescriptor>

The description for how to set up the WebLogic side says to use "default" as the "Target URL" and I assumed that this meant to leave it blank.  I think I followed the rest as described.

When I try to access a protected resource I get redirected to Shibboleth and then after authentication I get the error.  Here are the relevant (I hope) lines from the end of the log

17:59:15.174 - DEBUG [edu.internet2.middleware.shibboleth.idp.util.HttpServletHelper:307] - LoginContext key is '59ee968d-b4aa-47da-a703-dc22a1b1b57e'

17:59:15.174 - DEBUG [edu.internet2.middleware.shibboleth.idp.util.HttpServletHelper:310] - parition: loginContexts

17:59:15.174 - DEBUG [edu.internet2.middleware.shibboleth.idp.authn.AuthenticationEngine:170] - Returning control to profile handler at: /profile/Shibboleth/SSO

17:59:15.174 - INFO [Shibboleth-Access:73] - 20100504T235915Z|134.20.207.24|bea383438.inl.gov:443|/profile/Shibboleth/SSO|

17:59:15.174 - DEBUG [edu.internet2.middleware.shibboleth.idp.profile.IdPProfileHandlerManager:85] - shibboleth.HandlerManager: Looking up profile handler for request path: /Shibboleth/SSO

17:59:15.174 - DEBUG [edu.internet2.middleware.shibboleth.idp.profile.IdPProfileHandlerManager:93] - shibboleth.HandlerManager: Located profile handler of the following type for the request path: edu.internet2.middleware.shibboleth.idp.profile.saml1.ShibbolethSSOProfileHandler

17:59:15.174 - DEBUG [edu.internet2.middleware.shibboleth.idp.profile.saml1.ShibbolethSSOProfileHandler:112] - Processing incoming request

17:59:15.174 - DEBUG [edu.internet2.middleware.shibboleth.idp.profile.saml1.ShibbolethSSOProfileHandler:121] - Incoming request contains a login context, processing as second leg of request

17:59:15.174 - DEBUG [edu.internet2.middleware.shibboleth.common.relyingparty.provider.SAMLMDRelyingPartyConfigurationManager:126] - Looking up relying party configuration for http://bea383438.inl.gov:7001/

17:59:15.174 - DEBUG [edu.internet2.middleware.shibboleth.common.relyingparty.provider.SAMLMDRelyingPartyConfigurationManager:132] - No custom relying party configuration found for http://bea383438.inl.gov:7001/, looking up configuration based on metadata groups.

17:59:15.174 - DEBUG [edu.internet2.middleware.shibboleth.common.relyingparty.provider.SAMLMDRelyingPartyConfigurationManager:155] - No custom or group-based relying party configuration found for http://bea383438.inl.gov:7001/. Using default relying party configuration.

17:59:15.189 - DEBUG [edu.internet2.middleware.shibboleth.idp.profile.saml1.ShibbolethSSOEndpointSelector:78] - Selecting endpoint from metadata corresponding to provided ACS URL: 'http://bea383438.inl.gov:7001/samlacs/acs?APID=ap_00001'

17:59:15.189 - DEBUG [edu.internet2.middleware.shibboleth.idp.profile.saml1.ShibbolethSSOEndpointSelector:82] - Relying party role contains '0' endpoints

17:59:15.189 - DEBUG [edu.internet2.middleware.shibboleth.idp.profile.saml1.ShibbolethSSOEndpointSelector:101] - No endpoint meets selection criteria for SAML entity 'http://bea383438.inl.gov:7001/'

17:59:15.189 - ERROR [edu.internet2.middleware.shibboleth.idp.profile.AbstractSAMLProfileHandler:397] - No return endpoint available for relying party http://bea383438.inl.gov:7001/

I looked at the "common problems" explanation but I'm still not sure how to proceed.  Any thoughts?

Thank you,

Nick

[Chad La Joie]

The ACS URL is still wrong. I have no idea how you get WebLogic to
change it. That URL must match whatever is metadata and I'm pretty sure
can not contain any query params, according to the spec. I'm sure Scott
will correct me if I'm wrong on that.

On 5/4/10 8:21 PM, Nick Newman wrote:
> [edu.internet2.middleware.shibboleth.idp.profile.saml1.ShibbolethSSOEndpointSelector:78]
> - Selecting endpoint from metadata corresponding to provided ACS URL:
> 'http://bea383438.inl.gov:7001/samlacs/acs?APID=ap_00001'
> 17:59:15.189 - DEBUG
> [edu.internet2.middleware.shibboleth.idp.profile.saml1.ShibbolethSSOEndpointSelector:82]
> - Relying party role contains '0' endpoints
> 17:59:15.189 - DEBUG
> [edu.internet2.middleware.shibboleth.idp.profile.saml1.ShibbolethSSOEndpointSelector:101]
> - No endpoint meets selection criteria for SAML entity
> 'http://bea383438.inl.gov:7001/'
> 17:59:15.189 - ERROR
> [edu.internet2.middleware.shibboleth.idp.profile.AbstractSAMLProfileHandler:397]
> - No return endpoint available for relying party
> http://bea383438.inl.gov:7001/
>
> I looked at the "common problems" explanation but I'm still not sure how
> to proceed. Any thoughts?

[Scott Cantor]

> The ACS URL is still wrong. I have no idea how you get WebLogic to
> change it. That URL must match whatever is metadata and I'm pretty sure
> can not contain any query params, according to the spec. I'm sure Scott
> will correct me if I'm wrong on that.

It's not at all advisable, but it's not strictly illegal. Some people want
the freedom to use a query string but have the IdP ignore it during
comparison, but that's not supported by any reading of the spec. It should
be ok to put the query string into the metadata if it's required, but it
should be a fixed one.

(Of course, our code might not handle it though.)

I don't know if this one is supposed to be "fixed" or not either.

-- Scott

[Gregory Haverkamp]

I believe your problem is that your metadata is malformed.  You drop the "md" prefix for NameIDFormat and AssertionConsumerService.  Add the prefix to NameIDFormat (open and close) and AssertionConsumerService.  At least, that worked for me, and I successfully sent an assertion to your host that I can't actually connect to.

Greg

[Nick Newman]

Greg,

The namespace problem seems to have been it.  At least Shibboleth sends me back to WebLogic now so that I can continue the battle there...

What a rookie mistake!  I sometimes think there should be a law that all XML is validated against a schema on input.  (And I imagine that Shibboleth may have that option - this is not a complaint!)

Thanks to all for getting me past this sticking point.

Nick

[Scott Cantor]

> What a rookie mistake! I sometimes think there should be a law that all
XML
> is validated against a schema on input. (And I imagine that Shibboleth
may
> have that option - this is not a complaint!)

It is an option.

The libraries also work differently and some of the code also won't accept
unknown content inside of known structures and some of it will. The SP
wouldn't load that, for example, whether validation is on or not.

-- Scott

[abburukris]

I am new to shibboleth. I am trying to setup security on weblogic 10.3.3 with
saml 1.1 identity asserter talking to shibboleth. I would appreciate if
anyone could provide step by step instructions on how to set this up. I have
tried and it looks like I am missing something in the setup.

--
View this message in context: http://shibboleth.1660669.n2.nabble.com/Shibboleth-IdP-talking-to-WebLogic-10-3-SP-via-SAML-2-0-tp5001107p6287767.html
Sent from the Shibboleth - Users mailing list archive at Nabble.com.