2:44 p.m.
On 4/29/2013 12:04 PM, Darran Lofthouse wrote:
> 2. Ability to introspect principal and role mapping from
underlying
> "domain". We create a smart token from this information. With
> JBossWeb, we hacked this information from the Principal passed back from
> the security layer.
Currently we integrate with JAAS to get Undertow into WildFly but this
will be switched to PicketLink IDM.
So, should I wait before I port my oauth features?
However this is a second article I am putting together to clarify
the
situation regarding identity management. The central authentication
mechanisms by Undertow use a simplified IdentityManager interface that
exposes just the methods required by these mechansisms - there is
nothing to stop additional enhanced mechanisms from casting the
IdentityManager to an extended version that does provide the
capabilities needed by the mechanism.
I dont see why you couldn't add the ability to obtain role mappings.
Either you're leveraging Picketlink, and this information is available,
or, you're writing something specific for Undertow and the role mappings
would also be available. Doesn't seem like too far a stretch for me
that if you support isUserInRole(), that you couldn't have Set<String>
getRoles().
Overall Undertow does not impose a requirement on even using the
supplied IdentityManager - but I think really this is coming into the
WildFly integration side of things.
> 3. Ability to add additional action URLs to the web-app without
> additional user configuration. With JBossWeb, we handled all these URLs
> within a valve.
Would you consider this core to the WildFly integration or do you want
it to be an isolated 'drop in' mechanism? It is sounding to me as
though some of this would be better handled in the Undertow subsystem so
that a couple of steps of required initialisation could be handled by
just enabling one authentication mechanism.
I'm open to anything. What would be the best approach? My plan is to
keep this feature very specific to AS7 and Wildfly and not really
support it in other environments. I just don't have the time to
maintain integration with other containers.
> 4. Ability to create both principal and role mappings on the fly
from an
> incoming request's bearer token.
The authentication mechanism architecture should allow for this.
> 5. Ability to obtain any client certificates so that they can be
> verified. Verification only. For this I want to be able to verify the
> client that is acting on behalf of a user. So the calling client's
> certificates may not be the same identity of the actual user.
That information should be accessible - at the moment the current
implementation calls each method to attempt authentication until either
one succeeds or the list of mechanisms is exhausted or in a rare case if
one mechanism asks for the request to be bounced back to the calling
client. One thing that would need to be considered further would be if
you wanted multiple mechanisms to each successfully authenticate a small
part of the incoming request i.e. one check a cert used to establish the
connection, the next verify a header in the incoming request etc...
I'd like to be able to have a cert's signature verified by the web-app's
"domain" or web-app's Resteasy OAuth config. For JBossWeb this is a
global setting.
> 6. Ability to store state in-between requests. This isn't a
session as
> it will be two different clients that need to share data. in OAuth,
> there's the User Agent that establishes an access code for the web-app.
> The web-app makes a separate HTTP request to verify the access code
> and turn it into a token.
Again this is really an AS integration issue - for mechanisms like FORM
auth we do have some shared state that ends up being based on the HTTP
session but the architecture doesn't mandate anything like that.
Well, this was pretty simple with a JBossWeb valve. Because one valve
instance is instantiated per web app, I could just have a
concurrenthashmap store this information and spawn a very low priority
thread to reap unused entries.
> 7. Ability to log out any requested user. Our current
implementation
> has an admin interface that can log out a user on *every* app they are
> logged into.
This sounds like a management capability that would be added to the
WildFly integration. Probably quite closely related to how #6 would be
implemented.
Its one of those additional URL endpoints I as talking about. Just a
simple authenticated REST (HTTP) invocation.
> That's all I can think of now. So, Undertow needs to provide
these
> capabilities within their security API, *OR*, it requires a Valve
> architecture that can override any current built-in auth infrastructure,
> but at the same time, have access to the "domain" and be able to
> authenticate and introspect principal and role mappings.
Overall I think we need to check on point #5 but apart from that I think
the bulk of your requirements would really fit within the WildFly
integration.
Is the WIldfly integration something I'm going to have to wait on? Or
is there something usable right now?
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com