Accessing user attributes in login flow views

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

Accessing user attributes in login flow views

Ian Bobbitt-2
Is it possible to access resolved user attributes from login flow views?

I would like to be able to only render "login via $other_2nd_factor_solution" for users who can complete that method.

By the time the views I want to do this on run, the user principal is already populated, and the MFA script has already
resolved the attribute I need to look at.

-- Ian



--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Accessing user attributes in login flow views

Cantor, Scott E.
On 7/20/18, 2:50 PM, "users on behalf of Ian Bobbitt" <[hidden email] on behalf of [hidden email]> wrote:

> Is it possible to access resolved user attributes from login flow views?
> I would like to be able to only render "login via $other_2nd_factor_solution" for users who can complete that method.
>
> By the time the views I want to do this on run, the user principal is already populated, and the MFA script has already
> resolved the attribute I need to look at.

You can always access anything you yourself have put into the context tree, you just walk into it from the profileRequestContext variable if there's no faster route to it.

The only trick to bear in mind is that you can get into the subcontexts without needing access to the context's Java class object by calling getSubcontext("classname"), putting the class' name into a string literal. Velocity doesn't have access to real Java runtime stuff so you can't just easily get hold of class objects or create new objects, etc.

-- Scott


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Accessing user attributes in login flow views

Ian Bobbitt-2
On 7/20/18 2:54 PM, Cantor, Scott wrote:

> On 7/20/18, 2:50 PM, "users on behalf of Ian Bobbitt" <[hidden email] on behalf of [hidden email]> wrote:
>
>> Is it possible to access resolved user attributes from login flow views?
>> I would like to be able to only render "login via $other_2nd_factor_solution" for users who can complete that method.
>>
>> By the time the views I want to do this on run, the user principal is already populated, and the MFA script has already
>> resolved the attribute I need to look at.
> You can always access anything you yourself have put into the context tree, you just walk into it from the profileRequestContext variable if there's no faster route to it.
>
> The only trick to bear in mind is that you can get into the subcontexts without needing access to the context's Java class object by calling getSubcontext("classname"), putting the class' name into a string literal. Velocity doesn't have access to real Java runtime stuff so you can't just easily get hold of class objects or create new objects, etc.
>
> -- Scott
>
>
Thanks. That's the path I was going down, until I got stuck. I was loosely following the "Programmatically Selecting
Flows" MFA flow example[1], but wasn't sure how to get the attributes to actually resolve
("resCtx.resolveAttributes(custom)" where "custom" is an object-ref to "shibboleth.AttributeResolverService") and how to
do the actual value check ("valueType =  Java.type("net.shibboleth.idp.attribute.StringAttributeValue");" and "if
(attribute != null && attribute.getValues().contains(new valueType("Flow1"))) { ... }").

-- Ian

[1] https://wiki.shibboleth.net/confluence/display/IDP30/MultiFactorAuthnConfiguration


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Accessing user attributes in login flow views

Cantor, Scott E.
On 7/20/18, 4:30 PM, "Ian Bobbitt" <[hidden email]> wrote:

> Thanks. That's the path I was going down, until I got stuck. I was loosely following the "Programmatically Selecting
> Flows" MFA flow example[1], but wasn't sure how to get the attributes to actually resolve
> ("resCtx.resolveAttributes(custom)" where "custom" is an object-ref to "shibboleth.AttributeResolverService")

I doubt that would be very easy to do inside a template, you should resolve attributes before that were to render.

>  and how to
> do the actual value check ("valueType =  Java.type("net.shibboleth.idp.attribute.StringAttributeValue");" and "if
> (attribute != null && attribute.getValues().contains(new valueType("Flow1"))) { ... }").

You would have to do value checks by just looping and searching for a match, probably. Or using some really ugly tricks like creating objects through reflection perhaps.

-- Scott


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Accessing user attributes in login flow views

Ian Bobbitt-2
On 7/22/18 12:30 PM, Cantor, Scott wrote:
> On 7/20/18, 4:30 PM, "Ian Bobbitt" <[hidden email]> wrote:
>
>> Thanks. That's the path I was going down, until I got stuck. I was loosely following the "Programmatically Selecting
>> Flows" MFA flow example[1], but wasn't sure how to get the attributes to actually resolve
>> ("resCtx.resolveAttributes(custom)" where "custom" is an object-ref to "shibboleth.AttributeResolverService")
> I doubt that would be very easy to do inside a template, you should resolve attributes before that were to render.
>
Is there a suitable place in the context tree I could stash a couple booleans from the MFA script to reference more
easily from the views, or would I need to create my own class to put them in? (Is that even a good way to go about it? I
expect to only have about two values to check.)


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: Accessing user attributes in login flow views

Cantor, Scott E.
> Is there a suitable place in the context tree I could stash a couple booleans
> from the MFA script to reference more easily from the views, or would I
> need to create my own class to put them in? (Is that even a good way to go
> about it? I expect to only have about two values to check.)

There's nothing built-in until 3.4, there's a scratch storage mechanism there. Most people are bypassing the context tree for that kind of thing and just create conversation or flow scope variables, I think.

-- Scott

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Accessing user attributes in login flow views

Rod Widdowson
In reply to this post by Ian Bobbitt-2
> Is there a suitable place in the context tree I could stash a couple booleans from the MFA script to reference more easily from the
> views, or would I need to create my own class to put them in? (Is that even a good way to go about it? I expect to only have about two
> values to check.)

MHO: In general things never end up well if you try to borrow fields in existing structures that weren't design for that.  Just grow your own class...

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Accessing user attributes in login flow views

Jim Fox
In reply to this post by Ian Bobbitt-2

> Is there a suitable place in the context tree I could stash a couple booleans from the MFA script to reference more
> easily from the views, or would I need to create my own class to put them in? (Is that even a good way to go about it? I
> expect to only have about two values to check.)
>

You get a 'custom' object in your mfa scripts that is also passed to your
views.  Make your custom object a map, and set your booleans or whatever
in it.

Jim
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Accessing user attributes in login flow views

Cantor, Scott E.
> You get a 'custom' object in your mfa scripts that is also passed to your views.
> Make your custom object a map, and set your booleans or whatever in it.

If it's static, yes, but that doesn't work as conversational storage, he's just trying to store intermediate request state.

-- Scott

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Accessing user attributes in login flow views

Jim Fox

>
>> You get a 'custom' object in your mfa scripts that is also passed to your views.
>> Make your custom object a map, and set your booleans or whatever in it.
>
> If it's static, yes, but that doesn't work as conversational storage, he's just trying to store intermediate request state.
>

For that we do something like:

conversationScope = requestContext.getConversationScope();

conversationScope.put("duo_realuser", username);
etc.

Then it's available later with a get.

Jim

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Accessing user attributes in login flow views

Jim Fox

Forgot to add

   requestContext = input.getSubcontext("net.shibboleth.idp.profile.context.SpringRequestContext").getRequestContext();

Jim

>>> You get a 'custom' object in your mfa scripts that is also passed to your
>>> views.
>>> Make your custom object a map, and set your booleans or whatever in it.
>>
>> If it's static, yes, but that doesn't work as conversational storage, he's
>> just trying to store intermediate request state.
>>
>
> For that we do something like:
>
> conversationScope = requestContext.getConversationScope();
>
> conversationScope.put("duo_realuser", username);
> etc.
>
> Then it's available later with a get.
>
> Jim
>
>
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Accessing user attributes in login flow views

Cantor, Scott E.
In reply to this post by Jim Fox
> For that we do something like:
>
> conversationScope = requestContext.getConversationScope();
>
> conversationScope.put("duo_realuser", username); etc.
>
> Then it's available later with a get.

Right, thanks for saving me the need to dig up a sample.

-- Scott

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Accessing user attributes in login flow views

Ian Bobbitt-2
On 7/23/18 12:59 PM, Cantor, Scott wrote:

>> For that we do something like:
>>
>> conversationScope = requestContext.getConversationScope();
>>
>> conversationScope.put("duo_realuser", username); etc.
>>
>> Then it's available later with a get.
> Right, thanks for saving me the need to dig up a sample.
>
> -- Scott
>
Thanks! That got me what I needed.


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: Accessing user attributes in login flow views

Jim Fox
In reply to this post by Cantor, Scott E.

Please correct me if this isn't a good way.
To send a value from an MFA script to the view we do like this:

Our 'custom' Map has this entry

  <entry key="view" value-ref="shibboleth.CustomViewContext"/>

In the mfa script we do

  custom.get("view").put("duo_username", some_value);

And then use $custom.duo_username in the view.

Jim

On Mon, 23 Jul 2018, Cantor, Scott wrote:

> Date: Mon, 23 Jul 2018 09:59:04
> From: "Cantor, Scott" <[hidden email]>
> To: Shib Users <[hidden email]>
> Reply-To: Shib Users <[hidden email]>
> Subject: RE: Accessing user attributes in login flow views
>
>> For that we do something like:
>>
>> conversationScope = requestContext.getConversationScope();
>>
>> conversationScope.put("duo_realuser", username); etc.
>>
>> Then it's available later with a get.
>
> Right, thanks for saving me the need to dig up a sample.
>
> -- Scott
>
> --
> For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
> To unsubscribe from this list send an email to [hidden email]
>
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Accessing user attributes in login flow views

Cantor, Scott E.
> Please correct me if this isn't a good way.
> To send a value from an MFA script to the view we do like this:
>
> Our 'custom' Map has this entry
>
>   <entry key="view" value-ref="shibboleth.CustomViewContext"/>

That is likely a singleton, so it's not per-request, it would be overwritten by other requests, and be subject to the usual race conditions between separate users. The variable scopes accessed via RequestContext are inherently scoped to the flow conversations and are isolated from each other.

But it really depends what the Spring beans all look like I suppose.

Our intent is/was to keep everything in the context tree we manage in the IdP, and so I added a scratch storage capability for 3.4 that amounts to the same as the flow/conversation scopes but just less Spring webflow-specific.

-- Scott

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Accessing user attributes in login flow views

Jim Fox

OK, thnaks. I'll keep that in mind.

Jim

On Mon, 23 Jul 2018, Cantor, Scott wrote:

> Date: Mon, 23 Jul 2018 12:41:18
> From: "Cantor, Scott" <[hidden email]>
> To: Shib Users <[hidden email]>
> Reply-To: Shib Users <[hidden email]>
> Subject: RE: Accessing user attributes in login flow views
>
>> Please correct me if this isn't a good way.
>> To send a value from an MFA script to the view we do like this:
>>
>> Our 'custom' Map has this entry
>>
>>   <entry key="view" value-ref="shibboleth.CustomViewContext"/>
>
> That is likely a singleton, so it's not per-request, it would be overwritten by other requests, and be subject to the usual race conditions between separate users. The variable scopes accessed via RequestContext are inherently scoped to the flow conversations and are isolated from each other.
>
> But it really depends what the Spring beans all look like I suppose.
>
> Our intent is/was to keep everything in the context tree we manage in the IdP, and so I added a scratch storage capability for 3.4 that amounts to the same as the flow/conversation scopes but just less Spring webflow-specific.
>
> -- Scott
>
> --
> For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
> To unsubscribe from this list send an email to [hidden email]
>
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]