Fwd: AACLI thoughts

[Ryan Larscheidt]

> Well, we have the resolver and filter components, not sure where the
> encoder lives, but correct no AA in v3.

I saw this on the Shib Dev list, but thought it might be a more general question that should be posted to Users.

It sounds like the Attribute Authority functionality of the Shibboleth Identity Provider is going to be removed in version 3.  Is that correct?

Thanks,
Ryan

Begin forwarded message:

> From: Tom Zeller <tzeller at dragonacea.biz>
> Subject: Re: AACLI thoughts
> Date: March 19, 2013 21:02:54 CDT
> To: Shib Dev <dev at shibboleth.net>
> Reply-To: Shib Dev <dev at shibboleth.net>
> 
>> So in looking at porting AACLI over, I run into a quick disconnect. The
>> old code relies on a fairly weird, and I think unsatisfactory, little
>> beast called an "AttributeAuthority", which is this interface, coming in
>> SAML1 and SAML2 varieties, that glues together the general sequence of:
>> 
>> - resolve attributes
>> - filter them
>> - encode them in a SAML statement to dump
>> 
>> So the AACLI tool is really a shell around that particular pair of
>> components. I don't think we have those components right now in the V3
>> design, and I'm pretty sure that's intentional.
> 
> Well, we have the resolver and filter components, not sure where the
> encoder lives, but correct no AA in v3.
> 
>> It seems to me that the V3 equivalent of that is a sequence of flow
>> actions. What I'm wondering is, do we want to take the time to actually
>> implement it that way now, given that obviously we have no servlet engine
>> in which to put such a flow, so this would have to done as some kind of
>> alternate flow container. Which I'm guessing webflow might allow for, but
>> I haven't dug into webflow yet myself.
> 
> Modeling the AACLI as a flow sounds good to me.
> 
> I would have to look, but the resolve and filter attributes actions
> should already exist.
> 
> I don't think I committed it, but I had a very simple unit test class
> (based on work from Phil) which executes a flow outside of a servlet
> container, which I can send that your way. If I forget please ping me.
> 
>> Or do we want to port something tactically to manually execute a sequence
>> of activities inline so we can exercise the Spring container and resolver,
>> filter engine, etc. and worry about decomposing all of it later when we're
>> more into the webflow stage of work?
> 
> I suggest the manual execution of actions as a fallback (i.e.
> implement actions but manually execute the flow), or worst case no
> actions and let the AACLI implement the v2 AA functionality as you
> stated.
> 
> One of the last things Chad did was change our abstract profile
> actions to allow execution outside of web flow.
> 
>> I think that I like the idea, FWIW, of tackling this as my intro to
>> webflow and some of the profile action work, since it's pretty
>> self-contained, but that's obviously tacking a lot of overhead on getting
>> an AACLI done.
> 
> Probably time well spent, we need to know web flow better.
> --
> To unsubscribe from this list send an email to dev-unsubscribe at shibboleth.net

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 7327 bytes
Desc: not available
Url : http://shibboleth.net/pipermail/users/attachments/20130320/7d2dd1ad/attachment.bin