Re: [undertow-dev] resteasy oauth undertow security requirements

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 features.

>> >>>> 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. > 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 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. > 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.