[Shib-Dev] custom data resolver

[Paul Hethmon]

So I’m exploring creating a custom data resolver to allow my login handler to store attribute information that gets created during authentication.

In looking through the standard data resolver classes and the HttpServletHelper class, I can’t seem to find a clean way to tie the session information together. The session ID is available on both sides, but getting to the default storage service needs the servlet context.

What I’m thinking of doing is to create my own private storage service instance.

Has anyone done anything along these lines? Or maybe suggestions of what to explore?

I’m using Shib 2.1.5 as my base.

thanks,

Paul

[Chad La Joie]

Since you're creating a custom login handler, just create a custom
principal that carries the information you need. That'll get added to
the session and you can pull it from there in the attribute resolver.

On 8/16/10 5:31 PM, Paul Hethmon wrote:
> So I�m exploring creating a custom data resolver to allow my login

> handler to store attribute information that gets created during
> authentication.
>
> In looking through the standard data resolver classes and the

> HttpServletHelper class, I can�t seem to find a clean way to tie the

> session information together. The session ID is available on both sides,
> but getting to the default storage service needs the servlet context.
>

> What I�m thinking of doing is to create my own private storage service

> instance.
>
> Has anyone done anything along these lines? Or maybe suggestions of what
> to explore?
>

> I�m using Shib 2.1.5 as my base.
>
> thanks,
>
> Paul
>

--
Chad La Joie
http://itumi.biz
trusted identities, delivered

[Paul Hethmon]

So that still requires me to be able to obtain the session in the data
resolver which I don't see a way to do directly. So is this taking the
session id and using it to find the storage service for "session"?

On 8/16/10 5:54 PM, "Chad La Joie " <laj...@itumi.biz> wrote:

> Since you're creating a custom login handler, just create a custom
> principal that carries the information you need. That'll get added to
> the session and you can pull it from there in the attribute resolver.
>
> On 8/16/10 5:31 PM, Paul Hethmon wrote:

>> So I¹m exploring creating a custom data resolver to allow my login

>> handler to store attribute information that gets created during
>> authentication.
>>
>> In looking through the standard data resolver classes and the

>> HttpServletHelper class, I can¹t seem to find a clean way to tie the

>> session information together. The session ID is available on both sides,
>> but getting to the default storage service needs the servlet context.
>>

>> What I¹m thinking of doing is to create my own private storage service

>> instance.
>>
>> Has anyone done anything along these lines? Or maybe suggestions of what
>> to explore?
>>

>> I¹m using Shib 2.1.5 as my base.
>>
>> thanks,
>>
>> Paul
>>

[Paul Hethmon]

So I basically have this working now, though it feels a bit shaky in places.
It turns out I can't use the IdP session since its not created until my
login handler returns control to Shib. So I'm using the principal name as my
key to tie the attributes created at authentication back to the user in the
data resolver itself.

Using the principal name seems a bit of a shaky approach, though for my
deployments, I guarantee that one is present.

I never did see a way to create a custom principal and get that in the data
connector. The principal name as a string, but not a principal object.

Not really looking for any feedback at this point, just following up for the
list archives.

On 8/16/10 5:54 PM, "Chad La Joie " <laj...@itumi.biz> wrote:

> Since you're creating a custom login handler, just create a custom
> principal that carries the information you need. That'll get added to
> the session and you can pull it from there in the attribute resolver.
>
> On 8/16/10 5:31 PM, Paul Hethmon wrote:

>> So I¹m exploring creating a custom data resolver to allow my login

>> handler to store attribute information that gets created during
>> authentication.
>>
>> In looking through the standard data resolver classes and the

>> HttpServletHelper class, I can¹t seem to find a clean way to tie the

[Chad La Joie]

If you read the javadocs for the LoginHandler you can return a
username, a Principal, or full Subject object from there. That gets
added in to the Session and somewhere in the horrible hierarchy of the
profile request context the session is available to the resolver.

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

[Paul Hethmon]

I guess that means I should finish out my actual LoginHandler. I've been
piggybacking on the standard UsernamePassword handler and just replacing the
servlet itself.

I'll dig through the classes/methods again to see if I can find that link,
its eluded me thus far.

[Chad La Joie]

On Thu, Aug 19, 2010 at 17:52, Paul Hethmon
<paul.h...@clareitysecurity.com> wrote:
> I'll dig through the classes/methods again to see if I can find that link,
> its eluded me thus far.

Which link? accessing the Session from the request context? Or the
LoginHandler javadoc?

[Paul Hethmon]

On 8/19/10 5:53 PM, "Chad La Joie " <laj...@itumi.biz> wrote:

>> I'll dig through the classes/methods again to see if I can find that link,
>> its eluded me thus far.
>
> Which link? accessing the Session from the request context? Or the
> LoginHandler javadoc?

I've read the LoginHandler javadoc, so that one is ok. The part I can't find
way to get to the session information is from the DataConnector class:

public class AuthDataConnector extends BaseDataConnector {
public Map<String, BaseAttribute> resolve(ShibbolethResolutionContext
resolutionContext)
throws AttributeResolutionException {

try {
SAMLProfileRequestContext ctx =
resolutionContext.getAttributeRequestContext();
Session s = ctx.getUserSession();
String sid = s.getSessionID();

// The principal name is the index into our storage engine
Object o = AuthDataStorage.get(ctx.getPrincipalName());
if (o == null) {
LOG.debug("[{}]. Principal name not found.",
ctx.getPrincipalName());
attributes = new HashMap<String, BaseAttribute>(0);
return attributes;
}

So using the info from the wiki, I created my class extending
BaseDataConnector. During attribute resolution, I get the
ShibbolethResolutionContext object. As in my code snippet above, I can get
to the Session. Maybe this is where I'm missing it. I see I can do a
Session.getSubject, so would that be where my custom login handler would
insert the data from the authentication process? For simplicity right now, I
just created a custom class with a static storage in it.

Paul

[Chad La Joie]

It depends on what you return from the LoginHandler.

If you return a username, then the authentication engine will create a
UsernamePrincipal object, containing the user name you return, and add
it to the Subject in the session.

If you return a Principal object it just gets added to the Subject in
the session.

If you return a Subject then all of the principal names, public, and
private credentials get merged in to the Subject in the Session.

--