How to update IDP session user attributes?

[Chin]

Dear all,

Let say I have two SP:
1) SP-A
2) SP-B

Both connected to the same IDP.
When user login via SP-A and SAML Request is sent to the IDP, once
authentication is successful, SAML Response will return from IDP with
the following user attributes:

<saml:AttributeStatement>
<saml:Attribute Name="UserAccountName"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
<saml:AttributeValue type="xs:string" xsi:type="xs:string"
xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://
www.w3.org/2001/XMLSchema-instance">testing</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute Name="UserAccountID"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
<saml:AttributeValue type="xs:string" xsi:type="xs:string"
xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://
www.w3.org/2001/XMLSchema-instance">123456</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute Name="UserLanguage"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
<saml:AttributeValue type="xs:string" xsi:type="xs:string"
xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://
www.w3.org/2001/XMLSchema-instance">en</saml:AttributeValue>
</saml:Attribute>
</saml:AttributeStatement>

In short, it is just:
i) User name
ii) User ID
iii) User language.

For some reason, the user updated his language preference at SP-A, let
say from "en" to "fr".
When user visit SP-B, SP-B will of course send SAML Request to IDP and
because the user already login before at SP-A and hence IDP contain
the user session and SAML Response is returned to SP-B.

But at this point the SAML Response will contain the original user
language which is "en" but not the updated "fr".
So my question is, what is the standard and prefer method to update
the session in IDP so that it will reflects and changes made?

I understand we might be able to have the SP to do ForceAuth when
sending SAML Request. (But not sure if that will refresh IDP session
if session is already existed in IDP)

Not sure if anyone got any feedback, ideas, or solutions?

Thanks!

Best regards
Chin

[Peter Schober]

* Chin <mcc...@gmail.com> [2011-07-19 05:17]:

> I understand we might be able to have the SP to do ForceAuth when
> sending SAML Request. (But not sure if that will refresh IDP session
> if session is already existed in IDP)

Your IdP simply sends data it gathers from somewhere (e.g. an RDMBS,
or an LDAP directory). Whatever data you change elsewhere (e.g. on your
local computer or in an application that is protected by a SAML SP)
will not be magically transferred to the IdP.
Also ForceAuth will not make data from an application move to the data
store the IdP uses.
-peter

[Chin]

Thanks for the reply!

I am wondering if there is already a function I can call to somehow
"refresh" the IDP session, so that it will retrieve the latest user
attributes?
Or I will need to build my own customize module / functions to do so?
Or if someone got some other suggestions or solutions?

Thanks again!

Best Regards
Chin

On Jul 19, 11:17 am, Chin <mcc...@gmail.com> wrote:
> Dear all,
>
> Let say I have two SP:
> 1) SP-A
> 2) SP-B
>
> Both connected to the same IDP.
> When user login via SP-A and SAML Request is sent to the IDP, once
> authentication is successful, SAML Response will return from IDP with
> the following user attributes:
>
> <saml:AttributeStatement>
>   <saml:Attribute Name="UserAccountName"
> NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
>      <saml:AttributeValue type="xs:string" xsi:type="xs:string"

> xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">testing</saml:AttributeValue>

>   </saml:Attribute>
>   <saml:Attribute Name="UserAccountID"
> NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
>      <saml:AttributeValue type="xs:string" xsi:type="xs:string"

> xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">123456</saml:AttributeValue>

>   </saml:Attribute>
>   <saml:Attribute Name="UserLanguage"
> NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
>      <saml:AttributeValue type="xs:string" xsi:type="xs:string"

> xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">en</saml:AttributeValue>

[Peter Schober]

* Chin <mcc...@gmail.com> [2011-07-19 11:57]:

> I am wondering if there is already a function I can call to somehow
> "refresh" the IDP session, so that it will retrieve the latest user
> attributes?

Please re-read my previous email.
There is nothing to refresh on the IdP.

Changing data in one computer (say, SP-B) will not automagically
change data in another computer (say, your IdP).

The situation is different if your application stores its data in a
data store that the IdP actually uses for attribute lookup. You didn't
state that this is in fact the case, so I'm assuming it isn't.
-peter

[Chin]

Hi Peter,

Thanks again, I understand what you are trying to tell me.

Best regards
Chin

[Pontus Larsson]

Hi Peter,

But what about when the user-data is updated in the database used on the IDP?
Is there another way than logout the user and let them login again?

Just calling ->getAttributes() again simply returns the current session data that was retreived upon login.

I currently have 4 different sites that auth against 1 IDP and they seperatly have the possibility to update their own data on the IDP-database (via webservice).
Thanks in advance!
/Pontus

[Olav Morken]

On Thu, Mar 15, 2012 at 02:42:11 -0700, Pontus Larsson wrote:
> Hi Peter,
>
> But what about when the user-data is updated in the database used on the
> IDP?
> Is there another way than logout the user and let them login again?

Not with simpleSAMLphp. In theory, you could run attribute queries from
the SP to the IdP regularily in order to check if the user's attributes
have changed, but that requires support from both the IdP and the SP.
It is also rather ineffective if the attributes change very rarely.

Best regards,
Olav Morken
UNINETT / Feide

[Pontus Larsson]

Thanks.

Then the solution to display up-to-date data is for the user to logout and then login again.
But I agree, the data is changed rarely so this shouldn't be an issue.

/Pontus

[Joonas Meriläinen]

And again UX is being ignored. It seems that I have to redirect the user to the IdP to update their information (password, email), but how can I update or refresh the SAML session on the IdP, because it seems that I'm getting the old email address in the response after changing it. I'm already logging user out from SP, redirecting to IdP to update information, then logging in again to SP with a SAML request, but I still get the old information from the SAML session which has not been updated it seems. Forcing user to logout after updating email address seems silly, even though we are using it as a user name for logging in.

[Thijs Kinkhorst]

On 22Aug14 09:30, Joonas Meriläinen wrote:
> And again UX is being ignored. It seems that I have to redirect the user
> to the IdP to update their information (password, email), but how can I
> update or refresh the SAML session on the IdP, because it seems that I'm
> getting the old email address in the response after changing it. I'm
> already logging user out from SP, redirecting to IdP to update
> information, then logging in again to SP with a SAML request, but I
> still get the old information from the SAML session which has not been
> updated it seems. Forcing user to logout after updating email address
> seems silly, even though we are using it as a user name for logging in.

It seems like you are the SP, but the problem you're describing is
really something specific to the user's IdP.

If you invalidate the session on the SP and force a new SAML request,
but still get the 'old' data, the IdP is probably doing some kind of
single sign on where it keeps the logged in session active. So this is
something the user needs to solve with their IdP, because at the SP
you're already doing what you can: ask the IdP to send the attributes of
that user.

If the user changes attribute values at their IdP, it may make sense for
that IdP to invalidate any running sessions on the IdP for that user or
to update a running session with new attribute data. But this all
depends on how the IdP is implemented (and how the database backend
works - how do you know something was changed?). If the IdP uses
simpleSAMLphp, its administrator may be able to implement an extension
that triggers such an action when the database is updated.


Cheers,
Thijs

[Jaime Pérez Crespo]

Hi,

I would like just to remark that in a federated scenario the IdP and the SP are likely to be run by different organizations. That means the service providers won’t know about internals of a service, nor they should pretend to control anything on the IdP side. If a user wants to change his/her password or email, that’s a job for the IdP, not the SP. In that situation, you as a service provider would never know if a user changed password, email or whatever. Therefore, you won’t know if you have old or new attributes, you just have to trust what the IdP is providing you with.

Now, in the particular situation where you run both the SP and the IdP, you might want to somehow point the user from the SP to the IdP to change his information. I wouldn’t call that good practice, but ok. In that case, you know that a change *may* happen in the user’s attributes, and you would like to get fresh attributes for him/her. Since you are in a Single-Sign-On scenario, removing your session is useless because the IdP will still have a session. And you shouldn’t force a Single Logout for all services the user might be logged in just because you need a new attribute. What you could do, however, is to reauthenticate the user by redirecting him to the IdP, and ask the IdP to reauthenticate the user so that the new attributes are populated. You can use the ‘ForceAuthn’ option for that in the service provider.

Note that this would be a corner case, that you might not comply with all the “requirements” for it (and therefore you should not be worrying about this), and that in any case you definitely don’t want to kill Single-Sign-On by forcing the user to reauthenticate every time you ask for authentication if a session already exists.

More than a usability problem, I would say this is a problem related to not knowing the boundaries of your responsibilities.

--
Jaime Pérez
UNINETT / Feide
mail: jaime...@uninett.no
xmpp: ja...@jabber.uninett.no

"Two roads diverged in a wood, and I, I took the one less traveled by, and that has made all the difference."
- Robert Frost