Attributes and forwarding to Relay state
Kantzer, Chris E
Hello,
Is there a way that an attribute consumed from the saml assertion can be added to the request that is forwarded to the url in the relay state? The url in the relay state is on a different domain than the sp.
Some background:
We are creating a sp (sp.example.com) to process unsolicited idp requests from our client. The request will contain a saml response and a relay state to our struts web app (fooX.bar.com). The sp is not authenticating the user, just validating that the saml request did come from the client before forwarding the request to the relay state url. The url in the relay state could be different (foo1.bar.com, foo2.bar.com,etc) depending on the client type. The saml assertion contains a custom attribute called 'payload' that contains confidential client information. Our web application on fooX.bar.com needs that client information to lookup the client in our db.
Are the attributes added to the session that is created by the sp? Is this session forwarded to the relay state url even if they are on separate domains?
My apologies if I've missed documentation that answers this question.
Thanks.
Chris
Cantor, Scott
>Attributes and forwarding to Relay stateHello,
>Is there a way that an attribute consumed from the saml assertion can be
>added to the request that is forwarded to the url in the relay state?
>The url in the relay state is on a different domain than the sp.
That isn't secure. That would require an additional SSO protocol to secure
the exchange and is up to you to implement if that's what you want.
>Are the attributes added to the session that is created by the sp? Is
>this session forwarded to the relay state url even if they are on
>separate domains?
The session is bound to a cookie that has to be sent back to the SP on
every protected request. You cannot secure an application with the SP that
lives on a different server from the SP unless you deploy a second
protocol, or use the SP as a reverse proxy.
-- Scott
--
To unsubscribe from this list send an email to users-un...@shibboleth.net
Kantzer, Chris E
>That isn't secure. That would require an additional SSO protocol to
secure
>the exchange and is up to you to implement if that's what you want.
Okay, we will have to find a way to implement it.
But before I put the cart before the horse, I'm wondering if my
attribute config is correct.
I need to verify the 'payload' attribute is being processed from the
saml assertion.
I've created an attribute in attribute-map.xml which maps the saml
attribute with name 'payload' to an id of 'payload'.
Here's what I see in the logs when the sp is processing the saml
assertion:
DEBUG Shibboleth.SSO.SAML2 [1]: extracting pushed attributes...
DEBUG Shibboleth.AttributeExtractor.XML [1]: skipping unmapped NameID
with format (urn:oasis:names:tc:SAML:1.1:nameid-format:transient)
DEBUG Shibboleth.AttributeDecoder.String [1]: decoding SimpleAttribute
(payload) from SAML 2 Attribute (payload) with 1 value(s)
DEBUG Shibboleth.AttributeFilter [1]: filtering 1 attribute(s) from
(ALG_IP_10)
DEBUG Shibboleth.AttributeFilter [1]: applying filtering rule(s) for
attribute (payload) from (ALG_IP_10)
DEBUG Shibboleth.SSO.SAML2 [1]: resolving attributes...
DEBUG Shibboleth.AttributeResolver.Query [1]: found AttributeStatement
in input to new session, skipping query
DEBUG Shibboleth.SessionCache [1]: creating new session
2012-03-20 13:50:12 DEBUG Shibboleth.SessionCache [1]: storing new
session...
It looks like it's getting the attribute value correctly. But I'm not
sure where the value of payload is being stored and how I would access
it either through Apache or some other way.
Any advice would be helpful as I'm still learning this as I go.
FYI : Our SP is not protecting requests. It just is providing SSO
capabilities for our web app deployed on Weblogic (which is on a
different domain). Once the user is authenticated in our web app then
all requests go straight to the web app server, bypassing the sp.
Cantor, Scott
>
>It looks like it's getting the attribute value correctly. But I'm not
>sure where the value of payload is being stored and how I would access
>it either through Apache or some other way.
https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPAttributeAcces
s
>FYI : Our SP is not protecting requests. It just is providing SSO
>capabilities for our web app deployed on Weblogic (which is on a
>different domain). Once the user is authenticated in our web app then
>all requests go straight to the web app server, bypassing the sp.
Then you're trying to use the SP as some kind of SAML offloading agent,
and you really can't do that. You will need to deploy a second SSO
protocol between the box you're protecting with the SP and the box you
actually want to protect. That's a gateway. You can't do that with a
simple redirect.
You may be better off trying to use WebLogic's SAML support directly, or
put Apache in front of your WebLogic system. I would advise you to pick
one of those options. Adding a second protocol to the picture is more
work, less secure, and likely to be more brittle.
The SP is simply not meant to be a SAML solution for some other box on
your network. There are products out there better suited to that problem.
They are much worse at the SAML part, unfortunately.