Re: [security-dev] Undertow IDM

Bill Burke wrote: > Does Undertow give you some API so that you can get at the guts of a > SecurityCOntext? Basically the principal and its role mappings? Not directly, the principle and roles are determined by the relevant methods on the Account interface. Basically your auth mechanism could potentially just skip the IdentityManager entirely, and simply return its own account with whatever principal and roles you want. > > I really need to port my SSO/OAuth stuff to Undertow. I hope you're > still up for suggestions and API changes. But what I care most about is > that Undertow doesn't make it impossible to add these capabilities or > put undo configuration complexities that don't exist in the AS7 version > of this functionality. Darran started a thread about the configuration on undertow-dev a while back ("Web Application - Security Mechanism Selection"). The security API is not set in stone, if there are things that you need that we don't provide feel free to start a discussion on undertow-dev about it.

Stuart > > If you're interested, here's the gist. > > A user can turn on our SSO/OAuth support one web-app at a time. By > doing this multiple auth protocols and capabilitlies are automatically > added depending on how its deployed. > > You can turn a web-app into an auth server. This this means it > simultaneously supports: > > * FORM auth > * bearer token auth > * Additional action URLs to support OAuth token grants and SSO > > You can have a web-app delegate sign-on to a remote server. This means > it simultaneously supports: > > * An OAuth redirect login > * bearer token auth > * OAuth token grants (with the remote auth server as the authenticator) > > Only thing I care is that Undertow doesn't make it impossible to add > these capabilities. > > On 4/25/2013 4:06 AM, Darran Lofthouse wrote: >> One point - within Undertow access to the IDM should not necessarily be >> considered an authentication attempt, i.e. in Digest the IDM may be >> accessed even if the nonce is known to be out of date. >> >> However we do have a notification framework within Undertow for >> successful and failed authentication attempts - that would be a better >> point to handle any locking. >> >> Although at the same point would need be very careful how this is >> handled before it becomes an easy denial of service route. >> >> >> On 24/04/13 20:38, Pedro Igor Silva wrote: >>> I think PL IDM can supply most of the methods defined in the >>> IdentityManager interface. >>> >>> Only not sure about the somethings related with password reset and >>> account locking. Althought the Credential API maintains the history >>> of password updates and custom attributes can also be used. Not >>> sure, but maybe we should have that in PL IDM, built-in support for >>> password reset and account locking. >> > >>> Regarding DIGEST authentication and the getPassword method, if using >>> PL IDM this method is not necessary because we always store the HA1 >>> value (MD5(username:realm:password)). So you only need to pass the >>> provided password that it will be checked internally. >> That is going to be a bigger discussion but not one for this thread, in >> Undertow we need support for stronger hashes in addition to MD5 and also >> need access to the pre-hashed value at the very least to complete the >> Digest implementation. >> >>> Regards. >>> Pedro Igor >>> >>> ----- Original Message ----- >>> From: "Anil Saldhana"<Anil.Saldhana(a)redhat.com> >>> To: security-dev(a)lists.jboss.org >>> Sent: Wednesday, April 24, 2013 3:54:48 PM >>> Subject: [security-dev] Undertow IDM >>> >>> Hi all, >>> https://github.com/undertow-io/undertow/tree/master/core/src/main/java/io... >>> >>> >>> >>> I am wondering how we can use PicketLink IDM in Undertow. >>> >>> Regards, >>> Anil >>> _______________________________________________ >>> security-dev mailing list >>> security-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/security-dev >>> _______________________________________________ >>> security-dev mailing list >>> security-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/security-dev >>> >> _______________________________________________ >> security-dev mailing list >> security-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/security-dev >> >