For users created in UAA database, are there any policies we could apply
regarding password expiry/strength of the password/lockout on repeated
retry failures etc..?

Currently there is a password score calculator. There is a feature being
implemented for a more clearly configurable password strength. Expect it to
be in the next release. Lockout is implemented, and will also be
configurable in the next release.

+1 for password expiry; that'd be really handy to have.

On Sun, May 31, 2015 at 2:43 AM, Frans Thamura <frans(a)meruvian.org> wrote:

fyi, we use UAA for our social login , take a look www.merv.id

F
--
Frans Thamura (曽志胜)
Java Champion
Shadow Master and Lead Investor
Meruvian.
Integrated Hypermedia Java Solution Provider.

Mobile: +628557888699
Blog: http://blogs.mervpolis.com/roller/flatburger (id)

FB: http://www.facebook.com/meruvian
TW: http://www.twitter.com/meruvian / @meruvian
Website: http://www.meruvian.org

"We grow because we share the same belief."


On Sun, May 31, 2015 at 1:11 AM, Filip Hanik <fhanik(a)pivotal.io> wrote:

For users created in UAA database, are there any policies we could apply
regarding password expiry/strength of the password/lockout on repeated

retry

failures etc..?

Currently there is a password score calculator. There is a feature being
implemented for a more clearly configurable password strength. Expect it

to

be in the next release. Lockout is implemented, and will also be
configurable in the next release.

Is there any pluggable mechanism for user creation in UAA that we could

use

to create them say in AD – instead of in UAA user database?

The UAA can integrate with LDAP (AD) or with SAML IDPs. When you use one

of

these authentication mechanism, a shadow account will be created in the

UAA.

These users will only be able to authenticate against their respective
identity providers.

Is there any work/pocs done on UAA integration with Shibboleth Identity
provider to have federated identity? I.e. Integration with identity
providers behind firewalls?

I believe Shibboleth is a SAML v2 provider, so it should be able to be
configured like any other provider.

Is UAA HA/DR capable if the underlying user database is replicated?
Basically does it boil down to underlying UAA database HA/DR and any

tenants

identity provider’s HA/DR capability?

Yes, that is how we run our UAA in production. It's backed by a HA/DR
database.

Other than notion of Zones/Multi-tenants are there any advantages of

using

UAA over plain Spring Security OAuth2/Spring Cloud Security?

Yes, most of the work has already been done for you.


On Sat, May 30, 2015 at 11:58 AM, Reddy, Satyapal <

satyapal.reddy(a)emc.com>

wrote:

Looking into using UAA and have couple of questions:

For users created in UAA database, are there any policies we could apply
regarding password expiry/strength of the password/lockout on repeated

retry

failures etc..?
Is there any pluggable mechanism for user creation in UAA that we could
use to create them say in AD – instead of in UAA user database?
Is there any work/pocs done on UAA integration with Shibboleth Identity
provider to have federated identity? I.e. Integration with identity
providers behind firewalls?
Is UAA HA/DR capable if the underlying user database is replicated?
Basically does it boil down to underlying UAA database HA/DR and any

tenants

identity provider’s HA/DR capability?
Other than notion of Zones/Multi-tenants are there any advantages of

using

UAA over plain Spring Security OAuth2/Spring Cloud Security?

Thanks
Satya

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

--
Regards,

Daniel Jones
EngineerBetter.com