Bill Burke wrote:
I'm limited what I can do with my implementation right now because there
is no way to store additional metadata beyond user, password, and role
mappings. I can port what I have as-is to work under embedded
mode/testing mode, but a more rich IDM API would be needed for advanced
Is this just the ability to store arbitrary attributes under a user
account, and the getRoles() method? If this is all you require I think
we can just add them into the Undertow IDM interface.
>>>> 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...
This should be possible with the current architecture. You could have
one mechanism that returns NOT_ATTEMPTED if the certificates can be
verified, and FAILED if they can't be. I'm not sure if we would need
anything more than this.
>> 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
>> global setting.
> So is this done today using a per-app valve?
AS7 + JBossWeb can't do per-app client-cert verification. YOu have to
provide a truststore at the global configuration of the ssl connector.
It would be nice to be able to set the two-way SSL config at the global
level to be "WANT" and at the app level to "NEED" it.
>>>> 6. Ability to store state in-between requests. This isn't a session
>>>> 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
>>>> 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.
You could do the same thing in Undertow, but it just depends if you
would ever want to examine/manage this state in your admin console, in
which case it would probably need something more.
>>>> 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
>> Its one of those additional URL endpoints I as talking about. Just a
>> simple authenticated REST (HTTP) invocation.
> Hmm it sounds like we just need an SPI, and that you could allow apps access to that
SPI (verifying privileged actions etc)
Yeah, open on how to implement this going forward, but since Wildfly
wouldn't be SSO aware, it would have to be driven by the security layer.