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.

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

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. > Not really sure what you mean here? > 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. In that case you only need to implement the getHash() method, and just leave getPassword() returning null. In general one of the main aims of the Undertow IDM API is to be a wrapper that allows us to use the PL IDM without a direct dependency on PL, while also allowing us to integrate with what we currently have in the Wildly upstream. If there are potential changes that will make it easier to integrate with PL then I am happy to discuss them.

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

On 25/04/13 05: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. We already provide support for account locking: user.setEnabled(false); As for password reset, I really think that it's an application-specific function. It's really only a couple of lines of PLIDM code, the bulk of the work is building the user interface and action bean.

> 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. > > Regards. > Pedro Igor > > ----- Original Message ----- > From: "Anil Saldhana" <Anil.Saldhana(a)redhat.com&gt; > 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

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.

Regards. Pedro Igor ----- Original Message ----- From: "Anil Saldhana" <Anil.Saldhana(a)redhat.com&gt; 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

Does Undertow give you some API so that you can get at the guts of a SecurityCOntext? Basically the principal and its role mappings?

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. 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&gt; >> 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

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&quot;&lt;Anil.Saldhana(a)redhat.com&gt; >>> 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 >> >

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

I am not questioning anything. All I am trying to see how do we get PicketLink being able to run on Undertow because when we release PL3 in June, it should be Undertow ready. :)

On 04/25/2013 03:01 AM, Darran Lofthouse wrote: > Guys if you know I am working on a task can we please try and not start > a discussion during my down time - you have managed to go off on a > thread without even finding out the intention of the class in the first > place. > > * Firstly, why does Undertow have it's own IDM interface? > > It is undesirable for the Undertow project to be bringing in > dependencies on many different projects, an IDM provider being one of > them. > > For this reason Undertow has defined an interface for it's IDM > requirements, this effectively needs flagging as an spi but we have not > been through the exercise of separating out api from spi. > > * Secondly, how can we use PicketLink IDM in Undertow. > > PicketLink IDM is the whole reason for providing this interface, in the > AS integration a wrapper should be provided to supply an implementation > of this interface that delegates to PicketLink IDM. > > Do not get caught up on the Digest side as that is not quite complete, > although having said that I am not convinced the PicketLink > representation is complete either to fully support all aspects of Digest > plus stronger hashes but that is going to be a separate discussion. > > This interface still needs to evolve further with the following > priorities: - > - Provide the data / verification required by authentication > mechanisms within Undertow. > - Make it easy to wrap PicketLink IDM. > > For the latter point I don't believe we need a 1:1 mapping between the > two but we do need to aim to be close. > > Regards, > Darran Lofthouse. > > > On 24/04/13 19:54, Anil Saldhana wrote: >> 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

On 4/26/2013 4:01 AM, Darran Lofthouse wrote: > On 25/04/13 14:48, Anil Saldhana wrote: >> I am not questioning anything. All I am trying to see how do we get >> PicketLink >> being able to run on Undertow because when we release PL3 in June, it should >> be Undertow ready. :) > Hello Anil - my concern about this thread is we have numerous engineers > discussing how to integrate an aspect of an API that is already planned > to be modified ;-) > > As I said in my reply above, I will get some articles up clarifying the > current situation and then we can build from those. > FYI, I'm glad somebody is finally reworking, rewriting the web security API. Looking forward to work with it.