PersistentNameIDGenerationConfiguration: Type 4 UUID

[Hugo Slavia]

>I still don't know what you're asking. Literally, I am totally lost, I
don't know what your question is.

So currently we have base64 encoded Stored IDs --- all good.

However, per an org decision, we need the Stored IDs in UUID v4  ----- how
best to create UUID 4 type Stored IDs going forward -- i.e. new user
authenticated to Goggle; subsequent Stored ID for the user is UUID v4 (not
base64)?

On Tue, Jan 23, 2018 at 5:09 PM, Cantor, Scott <cantor.2 at osu.edu> wrote:

> On 1/23/18, 7:58 PM, "users on behalf of Hugo Slavia" <
> users-bounces at shibboleth.net on behalf of hugoslavia101 at gmail.com> wrote:
>
> > For Stored IDs  -- the options are base64 or base32
> (idp.persistentId.encoding).
>
> No, that's used for the hashed/computed version. The hash is binary so the
> encoding is the transform back into ASCII. You MUST use base32 if you want
> safe values. Base64 values are case sensitive and applications have botched
> this and do not allow use of case sensitive IDs, that's not safe.
>
> > What could be the options of generating Type 4 for the Stored ID?
>
> Stored IDs are UUIDs. But if you configure the IdP to generate the first
> generation of IDs using the computed strategy then you may never end up
> seeing any. That’s a migration tool to move from hashes to stored values.
>
> I still don't know what you're asking. Literally, I am totally lost, I
> don't know what your question is.
>
> -- Scott
>
>
>
> --
> For Consortium Member technical support, see https://wiki.shibboleth.net/
> confluence/x/coFAAg
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20180123/f9f913da/attachment.html>